[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: Here is a work-in-progress patch to test my idea: add "e" flag to open(). Limitations/TODO: * The unit test doesn't work on Windows (it requires fcntl) * "e" mode and the opener argument are exclusive: if O_CLOEXEC and O_NOINHERINT are missing, I don't see h

[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: > We should probably add this to 3.3 and default (IIRC O_CLOEXEC was added to the os module in 3.3). I created the issue #16860. I just realized that tempfile doesn't use open() but os.open(), so this issue help to fix #16860. -- _

[issue16850] Atomic open + close-and-exec

Charles-François Natali added the comment: > O_CLOEXEC solves for example a race condition in tempfile._mkstemp_inner(): > > fd = _os.open(file, flags, 0o600) > _set_cloexec(fd) Hum... """ diff --git a/Lib/tempfile.py b/Lib/tempfile.py --- a/Lib/tempfile.py +++ b/Lib/temp

[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: > So if we expose it and the underlying operating system doesn't support it, do you want to fallback to fcntl (which wouldb't be atomic anymore, but let's pretend the GIL protection is enough). At the beginning, I was convinced that the atomicity was important t

[issue16850] Atomic open + close-and-exec

Charles-François Natali added the comment: > 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 PO

[issue16850] Atomic open + close-and-exec

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

[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: > The feature looks to be supported by at least: > * FreeBSD 8+ Hum, it looks like it was only added to FreeBSD 8.3: http://www.freebsd.org/cgi/man.cgi?query=open&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html (O_CLOEXEC doesn't appea

[issue16850] Atomic open + close-and-exec

Charles-François Natali added the comment: I don't comfortable exposing this. The main reason is that this flag is really non-portable. Having open() fail at runtime because the platform doesn't support it looks really wrong to me. And silently ignore it is even worse. The 'x' flag was added bec

[issue16850] Atomic open + close-and-exec

Antoine Pitrou added the comment: > How about two options, like 'e' for guaranteed atomic CLOEXEC and 'E' > for CLOEXEC with or without atomic ops? Why would you want that? Best effort is sufficient. Also, I'm not sure why "e". -- nosy: +pitrou ___ P

[issue16850] Atomic open + close-and-exec

Changes by Ross Lagerwall : -- nosy: +rosslagerwall ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue16850] Atomic open + close-and-exec

Christian Heimes added the comment: Do you mean #12105? I didn't know about the ticket before. How about two options, like 'e' for guaranteed atomic CLOEXEC and 'E' for CLOEXEC with or without atomic ops? It's not much additional work and lowers the burden on the user. It's going to be hard t

[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: > You could do both: use the O_CLOEXEC flag and do a fcntl() call on POSIX This is the best-effort option. It was already discussed and rejected in the issue #12760. We had a similar discussion for the PEP 418 on monotonic clock. The final decision is not onl

[issue16850] Atomic open + close-and-exec

Christian Heimes added the comment: You could do both: use the O_CLOEXEC flag and do a fcntl() call on POSIX. In my opinion it's enough to document that the x flag may be affected by a race condition issue on some operation systems. -- nosy: +christian.heimes _

[issue16850] Atomic open + close-and-exec

STINNER Victor added the comment: > The problem is the find a portable and safe way to expose the feature A solution is to add a "e" mode to open() which would raise a NotImplementedError if the platform is not known to support this feature. For example, if the OS is linux, we would check if t

[issue16850] Atomic open + close-and-exec

New submission from STINNER Victor: Recent version on different operating systems support opening a file with close-on-exec flag set immediatly (atomic). This feature fixes a race condition when the process calls execv() between open() and fcntl() (to set the FD_CLOEXEC flag to the newly opene