On Thu, Nov 3, 2011 at 2:37 PM, Jeff Trawick <traw...@gmail.com> wrote: > On Thu, Nov 3, 2011 at 2:27 PM, Jim Jagielski <j...@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 <j...@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...
