select.select and socket.setblocking

[Saju Pillai]

Bryan Olson <fakeaddress at nowhere.org> wrote:

>
>Where does this come up? Suppose that to take advantage of multi-core 
>processors, our server runs as four processes, each with a single thread 
>that responds to events via select(). Clients all connect to the same 
>server port, so the socket listening on that port is shared by all four 
>processes. A perfectly reasonable architecture (though with many more 
>processes the simple implementation suffers the "thundering herd problem").


Which is why it is common for real world servers to serialize the
select()/accept() code - usually via a file lock or a semaphore.
-srp 
-- 
http://saju.net.in

>
>Two of our processors may be waiting on select() when a new connections 
>comes in. The select() call returns in both processes, showing the 
>socket ready for read, so both call accept() to complete the connection. 
>  The O.S. ensures that accept() [and recv()] are atomic, so one process 
>gets the new connection; what happens in the other depends on whether we 
>use a blocking or non-blocking socket, and clearly we want non-blocking.
>
>
>-- 
>--Bryan