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 -- http://mail.python.org/mailman/listinfo/python-list
