Aaron Bannert <[EMAIL PROTECTED]> writes:
> 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?
no... the semaphore is held only during the poll+accept
> 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?
Current code doesn't try to obtain the semaphore again if it is time
to go away.
> It still seems weird to
> me that we're essentially ignoring accept mutex errors during
> graceful.
(shrug)
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
