select.select and socket.setblocking

[Saju Pillai]

On Dec 31, 2:01 pm, Francesco Bochicchio <bock... at virgilio.it> wrote:
> Grant Edwards ha scritto:
>
> > On 2008-12-30, Francesco Bochicchio <bock... at virgilio.it> 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.
>
> Uhm. In my experience, with TCP protocol recv only returned less than
> the required bytes if the remote end disconnects. I always check the

What if the sending end actually sent less than you asked for ?

-srp

> returned value of recv and signal an error if the read bytes are less
> than the expected ones, but this error is never occurred (and its about
> 20 years that I use sockets in various languages and various flavor of
> unix and occasionally on windows. Maybe  have always been lucky ? :-)
>
> And, on some unices  system call recv also returns when a signal
> interrupts the syscall, but I half-remember reading that python recv in
> such a case repeat the system call by itself ... although this might be
> only my desire ...
>
> > 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.
>
> What I usually do, when I cannot block is:
>
> - use socket in blocking mode
> - do a select with a very small timeout and do a recv only if the select
> returns with input events
> - (with TCP) do a recv for the exact amount of bytes that I expect (
> this mean having a user protocol that carries the message size in the
> header, but this is usually the case ).
>
> This usually worked for me.
>
> If my process (or thread) has only to deal with socket I/O, I make a
> blocking select, and then make an 'exact' recv on whichever socket the
> select signals.
>
> Ciao
> ----
> FB