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. 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. 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. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
