Issue 36615: why call _Py_set_inheritable(0) from os.open() when O_CLOEXEC? (original) (raw)

When O_CLOEXEC is defined the file is opened with that flag (YA! - this means that the operation is atomic and, by default, the FD will be closed across os.posix_spawn()).

However the code then goes on an executes:

#ifndef MS_WINDOWS if (_Py_set_inheritable(fd, 0, atomic_flag_works) < 0) { close(fd); return -1; } #endif

should this also be #ifndef O_CLOEXEC?

The Linux kernel has a bad habit of ignoring unknown flags. If your libc is recent and contains O_CLOEXEC but your Linux kernel is old and doesn't know O_CLOEXEC, the flag will be simply ignored. It can happen when a Linux distribution builds a package with a recent kernel / libc, but you run an older kernel / libc. More info in the PEP 446:

https://www.python.org/dev/peps/pep-0446/#atomic-creation-of-non-inheritable-file-descriptors

if (_Py_set_inheritable(fd, 0, atomic_flag_works) < 0) {

Look for the atomic_flag_works: if it's 1, the function does nothing.

I don't think that this issue is a bug, so I suggest to close it. The bug tracker is not the right place to ask questions ;-)