apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_pipe.c apr_buckets_socket.c
Date Tue, 16 Jul 2002 19:33:14 GMT
  I think I have finally gotten to the bottom of this problem and have
discovered that it is a NetWare and very possibly a Win32 issue as well.
 The return value of the call to apr_bucket_read() on line #1283 in
protocol.c is compared against the macro APR_STATUS_IS_EAGAIN().  The
problem for both NetWare and Win32 is that this macros is defined to
test the rv against WSAEWOULDBLOCK rather than EWOULDBLOCK.  Since the
call to select() in apr_poll() actually returns EWOULDBLOCK for a pipe,
the comparison fails, the EWOULDBLOCK is not handled and the entire read
causes the browser return of "Premature end of script...".  I will be
submitting a NetWare patch for this problem as soon as I figure out what
the right thing is to do.  The Win32 platform should probably verify
that this isn't an issue on their platform as well.


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions

>>> Aaron Bannert <aaron@clove.org> Tuesday, July 16, 2002 12:09:04 PM
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
> > place.  If your analysis as to the definitions of APR_BLOCK_READ
> > APR_NONBLOCK_READ is correct, then let me dig a little deeper in
> > code to figure out exactly why MOD_CGI is ultimately passing an
> > APR_NONBLOCK_READ (unless somebody else already knows).  What I do
> > is that if pipe_socket_read() is allowed to return with an
> > 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
> Justin's definition is correct as far as I'm aware.
> At the risk of stating the obvious: EWOULDBLOCK can only be returned
> APR_NONBLOCK_READ mode.  Any caller that does a nonblocking read
> check for EWOULDBLOCK and loop or otherwise handle it.  (A tight
> 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
> stuff to do while waiting on more input.)

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


View raw message