httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: prefetch proxy
Date Thu, 03 Nov 2011 18:37:46 GMT
On Thu, Nov 3, 2011 at 2:27 PM, Jim Jagielski <jim@apache.org> wrote:
>
> On Nov 3, 2011, at 2:07 PM, Jeff Trawick wrote:
>
>> On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski <jim@jagunet.com> 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?
>>
>
> because that's not what is returned :)

I'm not disputing that there is some undiagnosed situation where
APR_ETIMEUP is seen.

I am looking for confirmation that APR_ETIMEUP is the expected value.

Given the available information I think it is better to assert() in
hops of getting doc on the real scenario rather than patch it over
here.  APR or some other layer may have a problem that will show up in
other places.

Mime
View raw message