Re: Problem found in perform_idle_server_maintenance on prefork.

[Greg Stein <gs...@lyra.org>]

On Wed, Feb 28, 2001 at 08:24:59PM +0000, Ben Laurie wrote:
> dean gaudet wrote:
> > and actually that graceful die flag might as well live in the scoreboard.
> > i can't remember why the graceful die flag doesn't live in the scoreboard
> > in 1.3... maybe i just never thought of it.  hrm.  i bet i just didn't
> > bother to move it there because 1.3 code had to be signal aware anyhow.
> > you may want to move this to the scoreboard in 2.0 to eliminate the
> > SIGWINCH in the children, it'll mean fewer potential problems with
> > non-signal aware 3rd party code.
> 
> IIRC, I originally put the graceful die flag in the scoreboard. The
> issue was that if your server wasn't heavily loaded, many child
> processes didn't ever wake up to discover they should die. So you had to
> signal to interrupt the accept() they were blocked in.

Hmm. Do we still block on accept()? Or do we block on select()? If the
latter, then we can wake them up with the "pipe of death" thingy.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Problem found in perform_idle_server_maintenance on prefork.

[rb...@covalent.net]

On Wed, 28 Feb 2001, Ben Laurie wrote:

> Greg Stein wrote:
> >
> > On Wed, Feb 28, 2001 at 08:24:59PM +0000, Ben Laurie wrote:
> > > dean gaudet wrote:
> > > > and actually that graceful die flag might as well live in the scoreboard.
> > > > i can't remember why the graceful die flag doesn't live in the scoreboard
> > > > in 1.3... maybe i just never thought of it.  hrm.  i bet i just didn't
> > > > bother to move it there because 1.3 code had to be signal aware anyhow.
> > > > you may want to move this to the scoreboard in 2.0 to eliminate the
> > > > SIGWINCH in the children, it'll mean fewer potential problems with
> > > > non-signal aware 3rd party code.
> > >
> > > IIRC, I originally put the graceful die flag in the scoreboard. The
> > > issue was that if your server wasn't heavily loaded, many child
> > > processes didn't ever wake up to discover they should die. So you had to
> > > signal to interrupt the accept() they were blocked in.
> >
> > Hmm. Do we still block on accept()? Or do we block on select()? If the
> > latter, then we can wake them up with the "pipe of death" thingy.
>
> Dunno, but I can't think why we couldn't block on select() if we don't
> already (except I'll wager there's some darn braindead system out there
> that won't let us).
>
> BTW, its coming back to me - it was even more elegant - in the
> scoreboard was a "current generation" number - if a child's own
> generation was not equal to the current generation, then it died.

That generation is still there.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

Re: Problem found in perform_idle_server_maintenance on prefork.

[Ben Laurie <be...@algroup.co.uk>]

Greg Stein wrote:
> 
> On Wed, Feb 28, 2001 at 08:24:59PM +0000, Ben Laurie wrote:
> > dean gaudet wrote:
> > > and actually that graceful die flag might as well live in the scoreboard.
> > > i can't remember why the graceful die flag doesn't live in the scoreboard
> > > in 1.3... maybe i just never thought of it.  hrm.  i bet i just didn't
> > > bother to move it there because 1.3 code had to be signal aware anyhow.
> > > you may want to move this to the scoreboard in 2.0 to eliminate the
> > > SIGWINCH in the children, it'll mean fewer potential problems with
> > > non-signal aware 3rd party code.
> >
> > IIRC, I originally put the graceful die flag in the scoreboard. The
> > issue was that if your server wasn't heavily loaded, many child
> > processes didn't ever wake up to discover they should die. So you had to
> > signal to interrupt the accept() they were blocked in.
> 
> Hmm. Do we still block on accept()? Or do we block on select()? If the
> latter, then we can wake them up with the "pipe of death" thingy.

Dunno, but I can't think why we couldn't block on select() if we don't
already (except I'll wager there's some darn braindead system out there
that won't let us).

BTW, its coming back to me - it was even more elegant - in the
scoreboard was a "current generation" number - if a child's own
generation was not equal to the current generation, then it died.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/