On Fri, Jun 01, 2001 at 04:08:25PM -0700, [EMAIL PROTECTED] 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))
worker_should_exit();
...
ap_mpm_pod_close(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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
