I should add a quick note about how
send() behave in non-blocking mode, when you have
called setblocking(False) on their socket. A `poll() loop like the one just shown means that we never
finish calling either of these functions when they cannot accept or provide data. But what if we find
ourselves in a situation where we want to call either function in non-blocking mode and do not yet know
whether the socket is ready?
recv() call, these are the rules:
Note that closed connection returns a value, but a still-open connection raises an exception. The logic behind this behavior is that the first and last possibilities are both possible in blocking mode as well: either you get data back, or finally the connection closes and you get back an empty string. So to communicate the extra, third possibility that can happen in non-blocking mode— that the connection is still open but no data is ready yet—an exception is used.
The behavior of non-blocking
send() is similar:
This evidence that
poll() could say that a socket is ready for sending, but a FIN packet from the client could arrive right
after the server is released from its
poll() but before it can start up its