apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: cvs commit: apr-util/buckets apr_buckets_pipe.c apr_buckets_socket.c
Date Tue, 16 Jul 2002 17:45:43 GMT
On Tue, 16 Jul 2002, Brad Nicholes wrote:

>    The problem with the MOD_CGI case is that it *doesn't* call
> pipe_bucket_read() with APR_BLOCK_READ.  In fact it calls it with
> APR_NONBLOCK_READ which is what prompted the modification in the first
> place.  If your analysis as to the definitions of APR_BLOCK_READ vs
> APR_NONBLOCK_READ is correct, then let me dig a little deeper in the
> code to figure out exactly why MOD_CGI is ultimately passing an
> APR_NONBLOCK_READ (unless somebody else already knows).  What I do know
> is that if pipe_socket_read() is allowed to return with an EWOULDBLOCK
> error code, I end up with a browser response of "Premature end of
> script..."  when in fact the data is there, just not at the right time.

Justin's definition is correct as far as I'm aware.

At the risk of stating the obvious: EWOULDBLOCK can only be returned in
APR_NONBLOCK_READ mode.  Any caller that does a nonblocking read *must*
check for EWOULDBLOCK and loop or otherwise handle it.  (A tight loop
doesn't make any sense, of course... if that's all you're going to do, use
APR_BLOCK_READ.  APR_NONBLOCK_READ is only any good if you have other
stuff to do while waiting on more input.)

--Cliff


Mime
View raw message