and socket.setblocking

Saju Pillai saju.pillai at
Sat Jan 3 21:44:09 CET 2009

Bryan Olson <fakeaddress at> 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.

>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.

More information about the Python-list mailing list