ncoghlan at gmail
Jul 26, 2013, 10:04 PM
Post #26 of 34
(70 views)
Permalink
|
|
Re: Inherance of file descriptor and handles on Windows (PEP 446)
[In reply to]
|
|
On 27 July 2013 14:36, Guido van Rossum <guido [at] python> wrote:
> On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith <greg [at] krypto> wrote:
>>
>> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou <solipsis [at] pitrou> wrote:
>>>
>>> On Sat, 27 Jul 2013 00:18:40 +0200
>>> Victor Stinner <victor.stinner [at] gmail> wrote:
>>> > 2013/7/26 Antoine Pitrou <solipsis [at] 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?
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 | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
