On Fri, 1 Jun 2001, Greg Stein wrote:
> 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.
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 [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
