[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets (original) (raw)

Victor Stinner victor.stinner at gmail.com
Fri Jul 5 08:24:11 CEST 2013

2013/7/5 Cameron Simpson <cs at zip.com.au>:

You might want to make clear that the "blocking" parameter refers only to the file creation calls (eg socket.socket) and not to the file descriptor itself, and is not to be confused with the UNIX ONONBLOCK file descriptor flag (and whatever equivalent flag may apply on Windows).

The two following codes are the same:

s = socket.socket(..., blocking=False)

and

s = socket.socket(...) s.setblocking(False)

Both set O_NONBLOCK flag (UNIX) or clear HANDLE_FLAG_INHERIT (Windows) on the socket (which is a file descriptor).

socket.socket(..., blocking=False) cannot fail with EAGAIN or EWOULDBLOCK (at least on Linux according to the manual page).

This is deducable from your PEP, but I was at first confused, and initially expected getblocking/setblocking functions in New Functions.

socket objects already have get_blocking() and set_blocking() methods. If we supported the blocking flag on any file descriptor, it would make sense to add such function to the os module. But I explained in the "Add blocking parameter for file descriptors and Windows overlapped I/O" section why I only want to set/clear the blocking file on sockets.

I would expect Popen and friends to need to both clear the flag to get the descriptors across the fork() call, and possibly to set the flag again after the fork. Naively, I would expect the the flag to be as it was before the Popen call, after the call.

As explained in the "Inheritance of file descriptors" section, the close-on-exec flag has no effect on fork:

"The flag has no effect on fork(), all file descriptors are inherited by the child process."

The close-on-exec flag is cleared after the fork and before the exec(). Pseudo-code for Popen:

pid = os.fork() if pid: return pid

child process

for fd in pass_fds: os.set_cloexec(fd, False) os.execv(...)

Victor

More information about the Python-Dev mailing list