select.select and socket.setblocking

[Bryan Olson]

Laszlo Nagy wrote:
[...]
> I have read the socket programming howto (
> http://docs.python.org/howto/sockets.html#sockets ) but it does not
> explain how a blocking socket + select is different from a non blocking
> socket + select. Is there any difference?

There is, but it may not effect you. There are cases where a socket can 
select() as readable, but not be readable by the time of a following 
recv() or accept() call. All such cases with which I'm familiar call for 
a non-blocking socket.

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

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