You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
socket.settimeout(t) -- can set the socket in blocking mode, when t==0.
socket.setblocking(flag) -- sets in blocking or non-blocking mode.
socket.gettimeout() -- returns 0 when socket is in non-blocking mode.
socket.gettimeout() is the only easy way of checking if the socket is non-blocking or blocking, but it's not intuitive to use it. It's especially strange that we have a setblocking() method without a corresponding getblocking().
I propose to add a 'socket.getblocking() -> bool' method.
It looks like we have a bug with 'sock.settimeout()' and non-blocking/blocking modes (or maybe this is a feature?)
to make a socket non-blocking, we call 'sock.settimeout(0)'.
to make a socket blocking, we call 'sock.settimeout(None)'.
What happens if we call sock.settimeout(t), where t > 0? The internal timeout field of the socket object will simply be set to 't'. What happens if the socket was in a non-blocking mode? Nothing, it stays in non-blocking mode.
What it means: suppose you have a non-blocking socket. You call socket.settimeout(10), and most likely you wanted to make it blocking again. Because all operations on the socket become blocking from moment (sock_call_ex repeats on EWOULDBLOCK and EAGAIN).
Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug?
It appears the the timeouts situation is a bit more complex. It's perfectly normal for a Python socket object to be in a "blocking" mode and for its FD to be in a non-blocking mode. Read more about this in the latest docs update to the PR: adcc91f