httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] get threaded MPM to terminate
Date Wed, 25 Apr 2001 00:22:38 GMT
>
> > On 24 Apr 2001, Jeff Trawick wrote:
> >
> > > > Why is this field going into the scoreboard?  This field is really private
> > > > to the child process, and doesn't need to go into shared memory.
> > > >
> > > > Can't the problem describes above be solved with a simple
> > > >
> > > >       workers_may_exit = 1;
> > > >
> > > > at line 732 of threaded.c?
> > >
> > > You're at least close to right.
> > >
> > > You still have the problem that there is nothing to wake up the worker
> > > threads; thus we need to write to the pipe of death as done in the
> > > patch.
>
> I believe Ryan is right here...
>
> All but one worker should be blocked on the accept mutex (find SAFE_ACCEPT() in
> threaded.c).  One worker is blocked in apr_poll().  When the parent writes to the pipe
of
> death, the thread in apr_poll is awakened and it is able to intuit if the pipe of death
> was written to or not, so it calls check_pipe_of_death(). If the pipe_of_death() was
> written to, workers_may_exit is set. Then the thread releases the accept mutex and
exits.
> The release of the accept mutex allows another thread to enter the locked region. The
very
> first thing it does is check workers_may_exit, sees that it is set, releases the accept
> mutex and exits.  This pattern should repeat untill all the workers have exited at which
> point the main thread pthread_join call fails allowing the main thread to exit.
>
> I don't think we need the workers_may_exit in shared memory because the accept_mutex
> guarantees no workers will sneak into the apr_poll() call.

BTW, this last point was a revelation to me up until 10 minutes ago. I just read the code
:-). I thought there was a race between setting workers_may_exit and workers going into
apr_poll.

Bill



Mime
View raw message