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:35:42 GMT
On Fri, 1 Jun 2001, Greg Stein wrote:

> On Fri, Jun 01, 2001 at 04:08:25PM -0700, rbb@covalent.net wrote:
> > On Fri, 1 Jun 2001, Greg Stein wrote:
> >...
> > > 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.
>
> ooh! Even better.
>
> I'd think we would read the P-o-D on re-entry to the listen loop. That
> allows a child to handle/complete an incoming request and then die (rather
> than accept a request, then throw it out because it saw "die").
>
> In your scenario, the "handle request" completes awfully quickly :-), then
> the P-o-D is read, and bye-bye.

Doesn't really matter when you do the check.  I agree 100% that we can't
just throw out the request, but we can check right after we are woken up,
and just set a flag.  Then, after we serve the request, we either go back
to sleep or die.  The only real difference is when we check the pipe, so
it is 6 of one, half a dozen of the other.

> > 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.
>
> Yup. We could probably have a few standard functions for opening, reading,
> and handling the P-o-D. The MPMs could then just do:
>
>     void *pod_ctx;
>
>     pod_ctx = ap_mpm_pod_open(...);
>
>     ...
>
>     if (ap_mpm_pod_check(pod_ctx))
>         worker_should_exit();
>
>     ...
>
>     ap_mpm_pod_close(pod_ctx);
>
>
> Although... actually, that last call just appears in worker_should_exit().

yep.  I may go ahead and implement this this weekend, because I really
like this.

> Not sure what sort of error returns and stuff would go into pod_check. I'm
> thinking none: it tells the work to continue or to exit (i.e. a simple
> boolean return flag). Internally, it handles any errors and makes a call on
> what to tell the worker.

I think I agree completely, but I want to think about it a bit more.

Ryan

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


Mime
View raw message