EAGAIN on write after poll() on Darwin (re: commit r160348)

[Wilfredo Sánchez Vega]

Mike Smith tells me that it's possible for poll() to tell you that a socket is writable and for the socket to change to an unwritable state before you get around to writing to it for a number of reasons. So it's reasonable (but presumably uncommon) to do a poll() then get back EAGAIN when you subsequently try to write(). Which implies that it may not be a bug in the OS after all.

If so, then the question is whether the correct fix would be in APR instead of in HTTPd, since HTTPd isn't really aware here that it's dealing with a non-blocking socket.

  Does this make sense?

    -wsv

On Apr 14, 2005, at 12:02 PM, Wilfredo Sánchez Vega wrote:

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