>
> > 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
