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.
Aaron
On Thu, 2006-11-16 at 11:57 +0100, Paul J Stevens wrote:
> Looks like I've nailed it already. Hang on.
>
> Paul J Stevens wrote:
> > Aaron,
> >
> > there's a serious problem in the select based setup.
> >
> > With the O_NONBLOCK flags, we run into problems with non-blocking client
> > sockets, even though I thought I had fixed this.
> >
> > Without the whole fnctl dance, children processes bailout without any
> > trace, and wihthout cleaning out the scoreboard, leaving the
> > parentprocess with a filled scoreboard without the related children.
> > I've tried fixing this by setting an atexit in the code, but for me that
> > doesn't fix it.
> >
> >
>
>
