On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith
On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou
wrote: On Sat, 27 Jul 2013 00:18:40 +0200 Victor Stinner
wrote: 2013/7/26 Antoine Pitrou
: On Fri, 26 Jul 2013 22:17:47 +0200
""" On Linux, setting the close-on-flag has a low overhead on performances. Results of bench_cloexec.py on Linux 3.6:
- close-on-flag not set: 7.8 us - O_CLOEXEC: 1% slower (7.9 us) - ioctl(): 3% slower (8.0 us) - fcntl(): 3% slower (8.0 us) """
You aren't answering my question: slower than what?
Ah, you didn't understand the labels. bench_cloexec.py runs a benchmark on os.open(path, os.O_RDONLY, cloexec=False) and os.open(path, os.O_RDONLY, cloexec=True) with different implementation of making the file descriptor non-inheritable.
close-on-flag not set: 7.8 us => C code: open(path, O_RDONLY)
O_CLOEXEC: 1% slower (7.9 us) => C code: open(path, O_RDONLY|CLOEXEC) => 1% slower than open(path, O_RDONLY)
ioctl(): 3% slower (8.0 us) => C code: fd=open(path, O_RDONLY); ioctl(fd, FIOCLEX, 0) => 3% slower than open(path, O_RDONLY)
fcntl(): 3% slower (8.0 us) => C code: fd=open(path, O_RDONLY); flags = fcntl(fd, F_GETFD); fcntl(fd, F_SETFD, flags | FD_CLOEXEC) => 3% slower than open(path, O_RDONLY)
Ok, so I think this it is a totally reasonable compromise.
People who bother about a 3% slowdown when calling os.open() can optimize the hell out of their code using Cython for all I care :-)
+1 ;)
and +1 for making the sane default of noinherit / cloexec / whatever-others-call-it by default for all fds/handles ever opened by Python. It stops ignoring the issue (ie: the status quo of matching the default behavior of C as defined in the 1970s)... That is a GOOD thing. :)
Do we even need a new PEP, or should we just do it? Or can we adapt Victor's PEP 446? -- --Guido van Rossum (python.org/~guido)