This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add a new optional timeout parameter to socket.socket() constructor
Type: enhancement Stage: resolved
Components: Versions: Python 3.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, neologix, pitrou, vstinner
Priority: normal Keywords:

Created on 2013-11-27 11:57 by vstinner, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg204575 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-27 11:57
Since Linux 2.6.28, socket() syscall accepts a new SOCK_NONBLOCK flag in the socket type. It avoids 1 or 2 extra syscalls to set the socket in non-blocking mode. This flag comes also slowly in other operating systems: NetBSD, FreeBSD, etc.

FreeBSD:
http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042242.html

Discussion in the POSIX standard:
http://austingroupbugs.net/view.php?id=411

Avoiding the syscalls has been proposed on python-dev a few months ago:
https://mail.python.org/pipermail/python-dev/2013-January/123661.html

I tried to include SOCK_NONBLOCK in my PEP 446, but I have been asked to treat it separatly because it's completly different than O_CLOEXEC (even it looks similar).
http://hg.python.org/peps/file/fa873d5aed27/pep-0446.txt#l64

I also proposed to add 2 functions in the PEP:

* ``os.get_blocking(fd:int) -> bool``
* ``os.set_blocking(fd:int, blocking: bool)``

I propose to add a new timeout parameter to socket.socket() constructor which would set the timeout internal attribute and set O_NONBLOCK flag using the new SOCK_NONBLOCK flag, ioctl() or fcntl() (depending on the OS and on what is available).

I don't know if something special should be done on Windows for non-blocking sockets? socket.socket.setblocking() already exists and I suppose that it works on Windows :-) See also the discussion in my old PEP for non-blocking operations in files on Windows:
http://hg.python.org/peps/file/fa873d5aed27/pep-0446.txt#l177

I don't know if the new parameter can just be added at the end of the parameter list, or it should be a keyword-only parameter to avoid breakpoint backward compatibility?

socket.socketpair() and socket.socket.dup() and socket.fromfd(), socket.create_connection() (and more generally any function creating a new socket) may also be modified.

--

By the way, internal_setblocking() currently uses 2 fcntl() syscalls on Linux, whereas it could be implemented with a single ioctl() syscall using FIONBIO.

Set O_NONBLOCK flag:

int flag = 1;
ioctl(fd, FIONBIO, &flag);

Clear O_NONBLOCK flag:

int flag = 0;
ioctl(fd, FIONBIO, &flag);

Tell me if you prefer a different issue for this optimization.
msg204576 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-27 12:02
Note: Python supports socket.SOCK_NONBLOCK since Python 3.2 (issue #7523).
msg204579 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-11-27 13:45
This really sounds pointless to me. How many sockets do you create per second?
msg204690 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2013-11-28 19:39
I'm with Antoine, this is *really* going too far.
SOCK_CLOEXEC and friends are useful to avoid race conditions: there's
no such concern with the non-blocking flag.
Shaving one or two syscalls is IMO completely useless, and doesn't
justify the extra code and, more importantly, clutter in the
constructor.
I'm -10.
msg204694 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2013-11-28 19:52
OK, let's forget about it.
msg204699 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-11-28 21:11
I don't see what I can do against a -10 vote! :-)

I opened the issue #19827 for the simple syscall optimization.
History
Date User Action Args
2022-04-11 14:57:54adminsetgithub: 64012
2013-11-28 21:11:54vstinnersetmessages: + msg204699
2013-11-28 19:52:23gvanrossumsetstatus: open -> closed
resolution: wont fix
messages: + msg204694

stage: resolved
2013-11-28 19:39:29neologixsetmessages: + msg204690
2013-11-27 13:45:15pitrousetmessages: + msg204579
2013-11-27 12:02:58vstinnersetnosy: + neologix
messages: + msg204576
2013-11-27 11:57:08vstinnercreate