httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: prefetch proxy
Date Thu, 03 Nov 2011 18:07:37 GMT
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski <> 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.
> From some research, it looks like EAGAIN is possible in
> inet_csk_wait_for_connect()

that's the accept() flow, right?

> as well as there being other
> people reporting similar "can't occur but does" with
> EAGAIN and reads... It looks like, at least according to
> recv() that EAGAIN is what we would get if a timeout
> occurs.

why not APR_ETIMEUP?

is it possible that the errno EAGAIN is observed from a syscall trace
for some problematic scenario that goes through this code, as opposed
to the read call returning APR_EAGAIN/EAGAIN to this code?

(errno may indeed be EAGAIN at this point if a read returns
APR_ETIMEUP if the poll/epoll/whatever doesn't modify errno when it
reports no events before reaching the timeout)

>  In any case, it doesn't seem right to fail in
> the *prefetch* stage if we get EAGAIN... if it is a
> "real" failure, let the remaining code path get it and
> handle it.

Born in Roswell... married an alien...

View raw message