On Thu, Nov 3, 2011 at 2:27 PM, Jim Jagielski <[email protected]> wrote: > > On Nov 3, 2011, at 2:07 PM, Jeff Trawick 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. >>>> >>> >>> >>> 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.
