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

[Gregory P. Smith]

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

> On Sat, 27 Jul 2013 00:18: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 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. :)

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130726/1cd8e72f/attachment.html>