On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote: > Aaron Bannert <[EMAIL PROTECTED]> writes: > > > On Tue, Mar 05, 2002 at 04:53:23PM -0500, Jeff Trawick wrote: > > > Here is the sequence of events: > > > > > > 1) a thread in child process A is waiting on semaphore > > > 2) graceful restart triggered > > > 3) parent process cleans up the semaphore > > > 4) that thread in child process A gets a failure (EIDRM) from the > > > semaphore obtain and gracefully brings down other threads in child > > > process A > > > > My point is that #3 and #4 are in the wrong order. There should be > > nobody waiting on a semaphore when the parent cleans it up. > > For a graceful restart, the parent can't wait around for all children > to go away before it cleans up and gets the next generation started. > It needs to let worker threads in the old children die gradually as > they finish processing active connection. That process can take a > long time.
Will they actually hold the semaphore while they are servicing long-lived connections? I guess we'd have to make it so that as soon as that worker* is done with that connection it checks to see if it is time to quit w/o hitting the semaphore again. Would that work? It still seems weird to me that we're essentially ignoring accept mutex errors during graceful. *"worker" meaning the smallest execution unit required to process a request, defined per-MPM. > (I thought about not cleaning up the semaphore at restart time, but > Greg pointed out that doing so doesn't allow the admin to change the > AcceptMutex foo setting without bringing down the server.) Yeah, that sounds reasonable to me. -aaron
