Okay, so it avoid the thundering herd problem if you call accept() orIt was thus said that the Great William Ahern once stated:
> On Thu, Dec 11, 2014 at 06:11:00PM -0500, Sean Conner wrote:
> > It was thus said that the Great William Ahern once stated:
> > > On Thu, Dec 11, 2014 at 12:31:28PM -0500, Sean Conner wrote:
> > > > It was thus said that the Great Valerio Schiavoni once stated:
> > > > >
> > > > > Due to continuous 'timeout' errors returned by the receiving socket (which
> > > > > is set to nonblocking, socket:settimeout(0)), the coroutine continuosly
> > > > > yields: in this case, is the reception of the data somehow put 'on hold' ?
> > > >
> > > > You don't need to set the socket to non-blocking if you use select just
> > > > for reading (and I just checked our codebase at work---I don't set any of
> > > > the sockets to nonblocking). All select() does is indicate when a file
> > > > descriptor (in your case, a network socket) has received data (ready for
> > > > reading), can write data without blocking (ready for writing ) or an
> > > > error happened.
> > >
> > > This is not true at all, and people who assume this are running code with
> > > TOCTTOU bugs. Spurious wakeups can be very common. There are two common
> > > scenarios.
> > >
> > > 1) Two threads reading from the same socket. Both get woken up, one drains
> > > the socket, the other ends up stalled. This is easy to avoid, but proves the
> > > point about the semantics of readiness notification. It applies equally to
> > > writability as to readability.
> > No true for Linux any more (this is the "thundering herd" problem). Now,
> > only one thread/process is woken up---the one that actually received the
> > packet.
> The thundering herd problem still exists except under very narrow
> conditions. In particular it's only fixed where at least one thread is
> already blocking on a read or accept call (i.e. not polling). Only then can
> the kernel atomically clear the ready state and dequeue the data.
read() directly on a socket, but not through select()/poll()/epoll(). Okay,
> > > Another poor assumption people make is thinking they don't need to set UDP
> > > sockets to non-blocking when writing, or even bother with polling for write
> > > readiness. Because UDP is lossy they assume that the kernel will simply drop
> > > any packet that won't fit in the output queue, immediately returning control
> > > to the writing thread. Not true, at least not on Linux. OTOH, Linux as a
> > > default socket buffer size of 65536 which means, again, you only trigger
> > > this bug under very heavy UDP load.
> > I'm not sure what distribution you are using, but I'm still running a
> > 2.6.9 kernel (32b) at home, and it reports a default UDP buffer size of
> > 110592; at work I'm running Linux 3.2.0 (64b) and it reports a default UDP
> > buffer size of 229376.
> Indeed. So for you it's 2x or 4x what I reported. On the most recent server
> I helped somebody fix this problem (a Java cluster doing billions of UDP
> requests daily), it was 64k, but perhaps that was something they set
> But you're only proving my point. The point was that the huge buffers common
> on Linux mask the problem except under heavy load. It's not until you begin
> to saturate the network and fill the buffer that your threads begin to stall
> when writing a UDP packet unless you set O_NONBLOCK.
Hmm ... (rushes off to fix code ... )
-spc ("Networking is hard! Let's do math!")