httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: idle server processes not going away
Date Fri, 01 Jun 2001 23:08:25 GMT
On Fri, 1 Jun 2001, Greg Stein wrote:

> On Fri, Jun 01, 2001 at 02:13:55PM -0700, rbb@covalent.net wrote:
> >...
> > I agree, but the problem now is how to solve
> > SINGLE_LISTEN_UNSERIALIZED_ACCEPT, and still respect graceful stop
> > requests for the child processes.  I still think that the best way to do
> > this, is to send OOB data to the child process through the same port that
> > the child has always listened to.  That allows the child to be woken up
> > out of the select call, and we can still use the signals for graceless
> > stopping of child processes.  Of course, this leads us open to DOS, if
> > done poorly.
>
> Nah... that isn't a DOS. The OOB just wakes the kid up. Then it should check
> a flag (dunno how; just talking thru it).
>
> If the OOB is the "die" flag, then you're right: total DOS and it wouldn't
> be workable.

ahhh....   yep, that would solve the DOS problem.

> Hmm. Maybe it would still have a P-o-D but not select/block on it. When it
> gets woken up with OOB data, *then* it would do a non-blocking read on the
> pipe. If something is there, then it dies.

That would work.  In reality if we do this, then we don't even need to use
OOB for the socket.  If we connect and close immediately, that wakes the
child up and it then checks the P-o-D.  This is no different than a client
connecting and never sending anything.

> An external client can get the thing to wake up, but they could do that
> anything by simply connecting to the port. So we're no worse off.
>
> Now the question is: do all TCP stacks support OOB sending/receiving? I know
> that the implementations are definitely different from one place to another
> when it comes to OOB.

See above, it doesn't matter.  :-)

I think this is a MUCH better implementation than we currently have.  This
also works for all MPMs, which means that any MPM can use S_L_U_A.

++1!

Ryan

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



Mime
View raw message