On 4/15/05, Joe Orton <[EMAIL PROTECTED]> wrote: > On Thu, Apr 14, 2005 at 12:02:35PM -0700, Wilfredo S�nchez Vega wrote: > > We're investigating possible issues in the system. One comment > > from a kernel developer: > > > > We are returning EWOULDBLOCK because the socket is in non-blocking. > > Inspecting the socket, so_state is 0x182 (0x100 is SS_NBIO). > > Setting > > a breakpoint on soioctl for SS_NBIO I can clearly see that httpd > > is setting the socket as non-blocking. httpd is using fcntl which > > translate the non-blocking change to an soioctl. > > > > Does it make sense that the socket is non-blocking? > > Recent httpd releases (2.0.49 onwards) will set listening sockets as > non-blocking if more than one listener is configured, to fix > CAN-2004-0174.
At the point of doing actual I/O, these sockets were non-blocking anyway as far as the kernel is concerned, because that is how APR implements I/O with timeout (tell kernel that socket is non-blocking, and handle EAGAIN/EWOULDBLOCK internally with poll()/select()). > This caused a number of obscure regressions on BSD platforms where APR > failed to detect (or, in some cases, the OS failed to correctly report) > whether or not O_NONBLOCK is inherited across to the socket returned by > accept(). That would be the first thing to check if you're seeing > issues like this - the test program APR uses is here: Another thing to check is if apr_poll() is telling the I/O routine that data is ready when in fact it is not. I recall some recent complaints about APR using poll() on OS X 10.3, where poll() has some negative attributes (I don't recall details).
