Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> I believe this is a bare-bones essential patch required for getting POD
> to work correctly under threaded MPM. The apr_recv() may return success
> but return 0 length (indicating the pipe is fine, but there were not any
> characters to read). Therefore, we should check the returned length
> being 1. The code in mpm_common.c already does this.
On what platform do you see rv APR_SUCCESS/len 0 when there is nothing
to read from the pipe?
Ooh, Solaris does this!
I think APR needs to hide this. Little issues like EAGAIN
vs. EWOULDBLOCK can be handled in apr status macros, but the
difference between APR_SUCCESS and something else is like night and
day.
Of course, it isn't the prettiest thing to implement. Here we're
using a socket call (apr_recv) on a pipe :) Only the file code knows
it is a pipe. You have to know it is a pipe to decide that rc==0 on
such a platform means EAGAIN.
> Index: threaded.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
> retrieving revision 1.44
> diff -u -r1.44 threaded.c
> --- threaded.c 2001/07/03 13:58:10 1.44
> +++ threaded.c 2001/07/17 22:29:52
> @@ -511,7 +511,8 @@
> else {
> /* It won the lottery (or something else is very
> * wrong). Embrace death with open arms. */
> - workers_may_exit = 1;
> + if (n == 1)
> + workers_may_exit = 1;
> }
> }
> apr_lock_release(pipe_of_death_mutex);
>
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
