httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: checking for EWOULDBLOCK/EAGAIN *inside* APR
Date Fri, 07 Apr 2000 20:38:33 GMT
> I must really be missing something.  But, I'll try one more time.
> In Apache 1.3, in src/main/buff.c on line 718 among others, we check for
> errno != EAGAIN.  This works on every platform that 1.3 works on.  We are
> not checking for EWOULDBLOCK here.  Why can't we do the same thing for 2.0
> in APR?

I cannot answer your question with 100% certainty.  A very quick grep/
browse of 1.3 (ignoring Win32 paths) shows that ap_bnonblock() is
called only from ap_send_fb_length(), and that only ap_bnonblock() has
code for Unix to mark a socket non-blocking.  Thus, I think the code
you point out is basically (or at least mostly) a no-op on 1.3 Unix. 

The point at which I hit the error on 2.0 is when we are waiting for
the request, so I am not close to that point.  Fairly frequently the
GET is not there at the point that we wake up and try the first
read()-type call to probe for data.

As far as getting EAGAIN/EWOULDBLOCK on a send()-type call after
ap_send_fb_length(): no useful comments really... There are some
implementation details in OS/390 TCP/IP which I think make it less
likely to hit the BSD-style send-buffer-full situation.

I can say without a shadow of a doubt that an app on OS/390 that uses
the UNIX APIs definitely does not get something that is equal to
EAGAIN when a read is attempted on a non-blocking socket and no data
is available.  Furthermore, I saw (in dbx) the lack of checking for
EWOULDBLOCK lead to a real problem.

> If this is a real bug, then just check for EAGAIN and EWOULDBLOCK in APR,
> and then return errno.  You are going to need to call
> ap_canonicalize_error in your app regardless of what Unix platforms do,
> because Windows doesn't return either one of these two errors.

o.k.  I think we're in agreement on what I should change.



View raw message