Jeff Trawick wrote:
>
>
> This patch moves the workers_may_exit field to the scoreboard and has
> the parent process set this field and bombard the pipe of death before
> sending SIGTERM to the child processes.
>
> The workers_may_exit field is Paul's new life_status field.
I'll try to answer Ryan's question about why it needs to go into the
scoreboard. Sorry for the long post, but it's a little tricky.
Basically we stole the idea from the prefork synchronization patch,
which a lot of Smart People contributed to. It is to eliminate the race
conditions that exist when the parent signals one or more children.
Let's say we just want to shut down. Assume one thread in one process
is sitting in apr_pool, waiting for an accept() or the pipe of death.
That process is pretty easy to deal with, as long as you remember to
write to the pipe of death (which we aren't now with the CVS code,
btw).
But the other processes which are blocked in mutex land are trickier.
The pipe of death doesn't do anything directly to unblock the mutexes,
and neither does the signal. However, since the apr_poll process is
going to be good, wake up, and start to go away, it will eventually
release the accept mutex to another process. Before this patch, it was
just looking at workers_may_exit, local to the process. So if the
signal thread hasn't been dispatched yet, it will just blow past that
test and think it should keep on working, and fall into the apr_poll
forever (unless Netscape/IE5/etc help us out by sending in new
connections). Remember we had to do the pipe of death earlier to wake
up the process which first owned the accept mutex.
Having the parent set the new life_status field in the scoreboard, and
using
that as workers_may_exit eliminates the race and the dependency on
enough browsers pounding the server in order for it to shut down.
>
> Try to ignore the mpm_trace() stuff in the patch...
>
No! I refuse! That's one of the best parts, especially when gdb doesn't
support threads on Linux, and threads libraries don't work on FreeBSD.
But yeah, it would be nice to spruce it up a bit so you could turn it on
and off from a config
directive, or better yet, the command line.
> Anything good in the following patch is from Greg Ames. The rest is
> mine.
>
uhhh, thanks, but I don't deserve that much credit. Several of us
brainstormed on it, and as I said, we stole ideas from the prefork
patch.
Greg
