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:
>> >
>> > Maybe I misunderstood, but I thought Rüdiger's original point was on
>> > track: EAGAIN here is a bug to fix somewhere since EAGAIN from
>> > blocking read is should-not-occur, and this code doesn't need to grow
>> > another error path.
>
> 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.
