Message308656
It looks like we have a bug with 'sock.settimeout()' and non-blocking/blocking modes (or maybe this is a feature?)
Currently:
* 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? |
|
Date |
User |
Action |
Args |
2017-12-19 15:56:14 | yselivanov | set | recipients:
+ yselivanov, pitrou, vstinner, njs, asvetlov |
2017-12-19 15:56:14 | yselivanov | set | messageid: <1513698974.74.0.213398074469.issue32373@psf.upfronthosting.co.za> |
2017-12-19 15:56:14 | yselivanov | link | issue32373 messages |
2017-12-19 15:56:14 | yselivanov | create | |
|