httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Tue, 05 Mar 2002 22:21:11 GMT
On Tue, Mar 05, 2002 at 05:07:38PM -0500, Jeff Trawick wrote:
> Aaron Bannert <aaron@clove.org> 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

Mime
View raw message