On 27 July 2013 14:36, Guido van Rossum <gu...@python.org> wrote: > On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith <g...@krypto.org> wrote: >> >> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou <solip...@pitrou.net> wrote: >>> >>> On Sat, 27 Jul 2013 00:18:40 +0200 >>> Victor Stinner <victor.stin...@gmail.com> wrote: >>> > 2013/7/26 Antoine Pitrou <solip...@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 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?
Adapting the PEP sounds good - while I agree with switching to a sane default, I think the daemonisation thread suggests there may need to be a supporting API to help force FDs created by nominated logging handlers to be inherited. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
