➜
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2017-12-19 14:23 byyselivanov, last changed2022-04-11 14:58 byadmin. This issue is nowclosed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 4926 | merged | yselivanov,2017-12-19 14:24 | |
| Messages (6) | |||
|---|---|---|---|
| msg308645 -(view) | Author: Yury Selivanov (yselivanov)* | Date: 2017-12-19 14:23 | |
Currently we have the following methods:* 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. | |||
| msg308656 -(view) | Author: Yury Selivanov (yselivanov)* | Date: 2017-12-19 15:56 | |
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? | |||
| msg308658 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-12-19 16:10 | |
> Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug?I agree it's a bug (but should only be fixed in 3.7).Also I agree with adding a socket.getblocking() method. | |||
| msg308663 -(view) | Author: Andrew Svetlov (asvetlov)* | Date: 2017-12-19 17:10 | |
Agree, it's a bug.+1 for getblocking() | |||
| msg308693 -(view) | Author: Yury Selivanov (yselivanov)* | Date: 2017-12-19 23:40 | |
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:https://github.com/python/cpython/pull/4926/commits/adcc91f93e1538f0d25645ebe0285b12137a3e3b | |||
| msg311019 -(view) | Author: Yury Selivanov (yselivanov)* | Date: 2018-01-28 22:27 | |
New changesetf11b460d8717fc3a5810684713b8b818f68789e8 by Yury Selivanov in branch 'master':bpo-32373: Add socket.getblocking() method. (#4926)https://github.com/python/cpython/commit/f11b460d8717fc3a5810684713b8b818f68789e8 | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:55 | admin | set | github: 76554 |
| 2018-01-28 23:18:40 | yselivanov | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
| 2018-01-28 22:27:40 | yselivanov | set | messages: +msg311019 |
| 2017-12-19 23:40:15 | yselivanov | set | messages: +msg308693 |
| 2017-12-19 17:10:41 | asvetlov | set | messages: +msg308663 |
| 2017-12-19 16:10:04 | pitrou | set | messages: +msg308658 |
| 2017-12-19 15:56:14 | yselivanov | set | nosy: +pitrou,njs messages: +msg308656 |
| 2017-12-19 14:24:57 | yselivanov | set | keywords: +patch stage: patch review pull_requests: +pull_request4820 |
| 2017-12-19 14:24:18 | yselivanov | set | nosy: +vstinner,asvetlov |
| 2017-12-19 14:23:24 | yselivanov | create | |