httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: idle server processes not going away
Date Fri, 01 Jun 2001 23:28:29 GMT
On Fri, Jun 01, 2001 at 04:08:25PM -0700, 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.

> > 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.  :-)

You bet :-)

> 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))


Although... actually, that last call just appears in worker_should_exit().

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.


Greg Stein,

View raw message