[Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446) (original) (raw)

Guido van Rossum guido at python.org
Sat Jul 27 06:36:01 CEST 2013

On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith <greg at krypto.org> wrote:

On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

On Sat, 27 Jul 2013 00🔞40 +0200 Victor Stinner <victor.stinner at gmail.com> wrote: > 2013/7/26 Antoine Pitrou <solipsis at pitrou.net>: > > On Fri, 26 Jul 2013 22:17:47 +0200 > >> """ > >> On Linux, setting the close-on-flag has a low overhead on > >> performances. Results of benchcloexec.py on Linux 3.6: > >> > >> - close-on-flag not set: 7.8 us > >> - OCLOEXEC: 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. benchcloexec.py runs a > benchmark on os.open(path, os.ORDONLY, cloexec=False) and > os.open(path, os.ORDONLY, cloexec=True) with different implementation > of making the file descriptor non-inheritable. > > close-on-flag not set: 7.8 us > => C code: open(path, ORDONLY) > > OCLOEXEC: 1% slower (7.9 us) > => C code: open(path, ORDONLY|CLOEXEC) > => 1% slower than open(path, ORDONLY) > > ioctl(): 3% slower (8.0 us) > => C code: fd=open(path, ORDONLY); ioctl(fd, FIOCLEX, 0) > => 3% slower than open(path, ORDONLY) > > fcntl(): 3% slower (8.0 us) > => C code: fd=open(path, ORDONLY); flags = fcntl(fd, FGETFD); > fcntl(fd, FSETFD, flags | FDCLOEXEC) > => 3% slower than open(path, ORDONLY) 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)

More information about the Python-Dev mailing list