On Thu, Nov 16, 2006, Paul J Stevens <[EMAIL PROTECTED]> said: > Aaron Stone wrote: >> Conflicting issues: >> http://cr.yp.to/unix/nonblock.html >> >> man 2 accept: >> NOTES >> There may not always be a connection waiting after a SIGIO is >> delivered or select(2) or poll(2) return a readability >> event because the connection might have been removed by an >> asynchronous network error or another thread before >> accept() is called. If this happens then the call will block >> waiting for the next connection to arrive. To ensure >> that accept() never blocks, the passed socket sockfd needs to >> have the O_NONBLOCK flag set (see socket(7)). >> >> Crap. >> >> Clearly it's safer to simply block on accept() if the connection is lost >> at that moment -- it might mean that another socket cannot be responded >> to for a while (and in pathlogical situations, a DoS against that other >> socket) but in the common case, and especially in the heavily loaded >> common case, everything keeps working just fine. > > > What we need to to is *force* the blocking state back on, after the accept.
But based on what DJB is saying that nonblocking refers to the kernel's ofile rather than to the individual instance of the fd, the nonblock dance in the middle of one process's accept might cause another process to have headaches in the middle of handling a normal session. Or is it that if several processes are woken up by select, that they all start racing through nonblock dance, and the saved state from F_GETFL isn't being reset because another process is picking up the non-blocking version? > What happens in 2.2.0 is somewhat similar to what is described above: a > child has done a O_NONBLOCK when another does F_GETFL. This way, the > client socket ends up being non-blocking - which is not what the calls > to fgets expect. Right, if it's just this and not my first interpretation of DJB, then we're ok if we just code around the issue a little bit. > So: either we make real sure the client socket is blocking, or we teach > all daemons to read from the clients in a non-blocking fashion. The > latter is what we want eventually (when we want to go async), but until > than, the first solution is simple and limited in scope. Ok, do you have code for it or should I dig into it in a few hours? Aaron
