On Sat, 27 Jul 2013 00:18:40 +0200
Victor Stinner <victor.stinner@gmail.com> wrote:
> 2013/7/26 Antoine Pitrou <solipsis@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 :-)