Select(2) is fundamentally broken

Re:Select(2) is fundamentally broken by majke on Friday January 06, 2017 @05:25AM (#13335274)

You are correct. Directly blocking on accept() in multiple processes does not have the "thundering herd" behaviour. This is good to know.

But this proves next point - select is a poor abstraction. This means that accept() is doing something more then just wait for readability (it attempts round robin) - a thing you can't express with select().

In the article I used the accept() case for illustration of the thundering herd problem. Non-blocking connect() taking a long time makes a good case. The same experiment could be done though measuring write() or sendmsg() syscalls.

[ Parent | on HN ]

Re:Select(2) is fundamentally broken by alexginzburg on Friday January 06, 2017 @08:38AM (#13336095)

First, the article starts talking about the accept() and thundering herd but the example shows use of the select().

Second, accept() goes over a queue of the established connections created by a listen() call

select() and accept() are meant for different things. selec/poll/epoll/kqueue work with a list of file descriptors to detect I/O, accept works with a socket.

[ Parent | on HN ]