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:38:10 GMT
On Thu, Nov 3, 2011 at 2:37 PM, Jeff Trawick <trawick@gmail.com> wrote:
> 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.

  ^^^^^^^^^^^^^^^
  APR_EAGAIN

>
> 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.
>



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

Mime
View raw message