Benjamin wrote: > I'm not sure it's worth cluttering the open() interface with such a > non-portable option. Zbyszek wrote: > If the best-effort fallback is included, it is quite portable. Definitely > all modern and semi-modern systems support either the atomic or the > nonatomic methods. Gregory wrote: > I'm not excited about raising an exception when it isn't supported; > it should attempt to get the same behavior via multiple API calls instead
Yes, I'm proposing the best-effort approach: use O_CLOEXEC/O_NOINHERIT if available, or fcntl()+FD_CLOEXEC otherwise. My patch requires fcntl() + FD_CLOEXEC flag or open() + O_NOINHERIT flag. I failed to find an OS where none of these flag/function is present. Usually, when I would like to test the portability, I test Linux, Windows and Mac OS X. Then I test FreeBSD, OpenBSD and OpenIndiana (Solaris). I don't test other OS because I don't know them and they are not installed on my PC :-) (I have many VM.) Should I try other platforms? Benjamin wrote: > People requiring such control should use the low-level os.open interface. os.open() is not very convinient because you have to chose the flag and the functions depending on the OS. If the open() flag is rejected, we should at least provide an helper for os.open() + fcntl(). The myriad cloexec APIs between different platforms suggests to me that using this features requires understanding its various quirks on different platforms. Victor 2013/1/8 Benjamin Peterson <benja...@python.org>: > 2013/1/7 Gregory P. Smith <g...@krypto.org>: >> >> >> >> On Mon, Jan 7, 2013 at 4:03 PM, Benjamin Peterson <benja...@python.org> >> wrote: >>> >>> 2013/1/7 Victor Stinner <victor.stin...@gmail.com>: >>> > Hi, >>> > >>> > I would like add a new flag to open() mode to close the file on exec: >>> > "e". This feature exists using different APIs depending on the OS and >>> > OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider >>> > that such flag would be interesting? >>> >>> I'm not sure it's worth cluttering the open() interface with such a >>> non-portable option. People requiring such control should use the >>> low-level os.open interface. >> >> >> The ability to supply such flags really belongs on _all_ high or low level >> file descriptor creating APIs so that things like subprocess_cloexec_pipe() >> would not be necessary: >> http://hg.python.org/cpython/file/0afa7b323abb/Modules/_posixsubprocess.c#l729 > > I think the open() interface should have consistent and > non-conditional support features to the maximum extent possible. The > recent addition of "x" is a good example I think. The myriad cloexec > APIs between different platforms suggests to me that using this > features requires understanding its various quirks on different > platforms. > > > > -- > Regards, > Benjamin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
