The current fix is very minimal, and I believe it does the trick. But looking into it some more, I think we can make a slightly broader change that has the same effect but with fewer calls to fcntl...
On Fri, 2006-11-17 at 09:53 +0100, Paul J Stevens wrote: > Aaron, > > looking at your patch; why do we need to restore the blocking flags on > the listenSocket? Isn't it enough to just force blocking on the client > socket? I think I was assuming that select only wants to look after blocking sockets. But that doesn't make much sense. So we could just mark all of the listenSockets as non-blocking when we first create them in the parent process, and then when we accept() and get a clientSocket, make just the clientSocket blocking, as you've suggested. We should check to see if the listen sockets inherit blocking state after fork(). I would assume that this is the case, but I don't know for a fact. If so, then we don't have to do any dance at all, and can indeed simply mark the listen sockets as non-blocking in the parent. A test harness should open a *lot* of new connections and immediately drop them so that we can try to wedge the process at accept() and then see what code changes prevent that. The test case I have in mind is to start up a dbmail daemon with two listen ip's. Then we open and drop a few thousand connections on one ip, then see if any processes are still listening to another ip. Aaron
