STINNER Victor added the comment: "Note that I don't like the idea of falling back to FD_CLOEXEC since it's not atomic, and some people might rely on this."
There is a similar question (atomic or best effort) for the #16860 issue. It looks like more people prefer the best effort option. IMO most people prefer to use the best available method to set the close-on-exec flag, but doesn't really care if the method is not atomic (and the OS doesn't provide an atomic function). If someone cannot accept the best effort option: I guess that it is still possible to override TCPServer constructor to ensure that the action is atomic. "It would already be a nice piece of progress if you could request the SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even with a module variable." Yes, close-on-exec flag should be configurable, as TCPServer.allow_reuse_address for example. I like the class attribute, something like TCPServer.close_on_exec, False by default, for example. -- "I realize this bugreport cannot fix 35 years of a bad design decision in linux." Well... Ruby made a brave choice :-) Ruby (2.0?) does set close-on-exec flag on *ALL file descriptors (except 0, 1, 2) *by default*: http://bugs.ruby-lang.org/issues/5041 This change solves the problem of having to close all file descriptor after a fork to run a new program (see closed Python issues #11284 and #8052)... if you are not using C extensions creating file descriptors? Ruby applications relying on passing FD to child processes have to explicitly disable close-on-exec the flag: it was done in Unicorn for example. "But we can't simply change the default to FD_CLOEXEC, for two reasons: - we can't silently change the Unix semantics - this is going to break some applications: for example, FD inherited across exec is used by super servers such as inetd, and there are others very legitimate uses" Yes, changing the default value of the flag (enable close-on-exec by default) will break some applications. But if we chose to do it, developers of these applications can still disable close-on-exec (because the option must be configurable) to fix their application for Python 3.4. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12107> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
