Re: svn commit: r160348 - httpd/httpd/trunk/server/core_filters.c

[Wilfredo Sánchez Vega]

We're investigating possible issues in the system. One comment from a kernel developer:

We are returning EWOULDBLOCK because the socket is in non-blocking.
Inspecting the socket, so_state is 0x182 (0x100 is SS_NBIO). Setting
a breakpoint on soioctl for SS_NBIO I can clearly see that httpd
is setting the socket as non-blocking. httpd is using fcntl which
translate the non-blocking change to an soioctl.

  Does it make sense that the socket is non-blocking?

    -wsv

On Apr 7, 2005, at 7:00 AM, Paul Querna wrote:

Jeff Trawick wrote:

On Apr 6, 2005 8:22 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: wsanchez
Date: Wed Apr  6 17:22:29 2005
New Revision: 160348

URL: http://svn.apache.org/viewcvs?view=rev&rev=160348
Log:
In emulate_sendfile(), handle APR_EAGAIN from apr_socket_send().
- rv = apr_socket_send(c->client_socket, &buffer[o], &bytes_sent);
- *nbytes += bytes_sent;
- if (rv == APR_SUCCESS) {
- sendlen -= bytes_sent; /* sendlen != bytes_sent ==> partial write */
- o += bytes_sent; /* o is where we are in the buffer */
- togo -= bytes_sent; /* track how much of the file we've sent */
+ if (rv == APR_SUCCESS && sendlen) {
+ while ((rv == APR_SUCCESS || rv == APR_EAGAIN) && sendlen) {

Why would EAGAIN be returned? There should be a timeout set on the
APR socket. Either the send works within the timeout period or we get
timeout error or we get some lower-level socket error.
If EAGAIN is really returned, I suspect there is something else to investigate.

Yes, I was talking to wsanchez on IRC, and I suspect there might be a bug in the OS-X kernel, causing a blocking socket to return EAGAIN on write().

smime.p7s

Description: S/MIME cryptographic signature