On Thu, Nov 3, 2011 at 4:09 PM, Jeff Trawick <[email protected]> wrote:
> On Thu, Nov 3, 2011 at 3:38 PM, Greg Ames <[email protected]> wrote: > > On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski <[email protected]> wrote: > >> > >> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote: > >> > > > > I worked on a bug about a year ago that turned out to be AIX > intermittently > > returning early from a poll() for readability on a socket, then returning > > EAGAIN on the following read(). See APAR IZ81307 for the gory details. > The > > input filters had a blocking option set, but we implement it with a > poll() > > followed by a non-blocking read(). It caused empty buckets to get > passed up > > the input filter chain which caused other odd symptoms. > > > > Although the low-level details surely differ, that seems to be > something to be caught in APR if the fix is outside of our code. > (ISTR something vaguely familiar with pipes that required > > I guess we're using some read logic other than this? > > apr_status_t apr_socket_recv(apr_socket_t *sock, char *buf, apr_size_t > *len) > { > ... > do { > rv = read(sock->socketdes, buf, (*len)); > } while (rv == -1 && errno == EINTR); > > while ((rv == -1) && (errno == EAGAIN || errno == EWOULDBLOCK) > && (sock->timeout > 0)) { > do_select: > arv = apr_wait_for_io_or_timeout(NULL, sock, 1); > if (arv != APR_SUCCESS) { > *len = 0; > return arv; > } > else { > do { > rv = read(sock->socketdes, buf, (*len)); > } while (rv == -1 && errno == EINTR); > } > } > > It seems resilient (though perhaps cpu-loopy) to unexpected poll pop. > > If some other code has screwed around with the timeout setting and not > restored it then EAGAIN is not surprising. > I probably saw it on an older version of this code without the while (EAGAIN) loop. I coded something like that for a circumvention. Greg
