apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: apr-util/buckets apr_buckets_pipe.c apr_buckets_socket.c
Date Tue, 16 Jul 2002 18:09:04 GMT
On Tue, Jul 16, 2002 at 01:45:43PM -0400, Cliff Woolley wrote:
> 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.)

Can someone please document with this level of detail in the header?
Pleeease? :)


View raw message