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