and socket.setblocking

Jean-Paul Calderone exarkun at
Tue Dec 30 21:55:51 CET 2008

On Tue, 30 Dec 2008 14:41:17 -0600, Grant Edwards <grante at> wrote:
>On 2008-12-30, Francesco Bochicchio <bockman at> wrote:
>> 3. AFAIK (sorry, I feel acronym-ly today ;), there is no difference in
>> select between blocking and non-blocking mode. The difference is in the
>> recv (again, assuming that you use TCP as protocol, that is AF_INET,
>> SOCK_STREAM), which in the blocking case would wait to receive all the
>> bytes that you requested,
>No, in blocking mode it will wait to receive _some_ data (1 or
>more bytes).  The "requested" amount is strictly an upper
>limit: recv won't return more than the requested number of
>bytes, but it might return less.

Hi Grant,

I don't think you read Francesco's message carefully enough. :)  He said:

>>there is no difference in select between blocking and non-blocking mode.

You're describing a difference in recv, not select.

>In non-blocking mode, it will always return immediately, either
>with some data, no data (other end closed), or an EAGAIN or
>EWOULDBLOCK error (I forget which).
>> [...] I myself tend to avoid using non-blocking sockets, since
>> blocking sockets are much easier to handle...
>That depends on whether you can tolerate blocking or not.  In
>an event-loop, blocking is generally not allowed.

If you're careful, it's possible to avoid blocking, even when using a
blocking socket, at least for AF_INET, SOCK_STREAM sockets.  Of course,
it's easier to avoid blocking by using a non-blocking socket.


More information about the Python-list mailing list