[issue16850] Atomic open + close-and-exec

[STINNER Victor]

STINNER Victor added the comment:

> Also, I'm not sure why "e".

The choice of the "e" letter comes from the GNU version of fopen(). Extract of fopen manual page on Linux:

       e (since glibc 2.7)
              Open the file with the O_CLOEXEC flag.  See open(2) for more information.

Oh, by the way: "e" mode is a best-effort approach. It uses fcntl() if O_CLOEXEC is not supported by the running kernel. fopen() doesn't check the kernel version, but pass O_CLOEXEC and check (once) if FD_CLOEXEC is set:

http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c;h=61b61b30d88d0fca9e6b20a2fe62a2406cc027cf;hb=HEAD#l319

It's interesting to know that the glibc chose the best-effort approach.

> The 'x' flag was added because it is useful, on available on all
> platforms (I mean, even Windows has it). Here's, it's by definition
> Unix-specific, ...

Windows provides O_NOINHERIT (_O_NOINHERIT) flag which has a similar purpose.

> ... and even then, many Unices don't support it.

Yes, but I bet that more and more OSes will support it :-) For example, it looks like O_CLOEXEC is part of the POSIX standard 2008:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
("O_CLOEXEC: If set, the FD_CLOEXEC flag for the new file descriptor shall be set.")

The O_CLOEXEC flag of Linux comes from QNX and BeOS which support it since many years (I don't know when, at least since 2004).

So O_CLOEXEC is not really specific to Linux.

--

For more information of the Linux support, this article of Ulrich Drepper contains many useful information:
http://udrepper.livejournal.com/20407.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16850>
_______________________________________