On Sun, 28 Jul 2013 02:39:19 +0200 Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > I have a few more questions on the PEP 446: > > (A) How should we support support where os.set_inheritable() is not > supported? Can we announce that os.set_inheritable() is always > available or not? Does such platform exist?
FD_CLOEXEC is POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html > (B) Should subprocess make the file descriptors of pass_fds > inheritable? If yes, should it be done before or after the fork? If it > is done after the fork and before exec, it only affects the child > process, at least on Linux (the file descriptor is still > non-inheritable in the parent process). If it is done, it should definitely be done after the fork, IMO. subprocess shouldn't have any long-lasting effects on the process. > (C) Should we handle standard streams (0: stdin, 1: stdout, 2: stderr) > differently? For example, os.dup2(fd, 0) should make the file > descriptor 0 (stdin) inheritable or non-inheritable? On Windows, > os.set_inheritable(fd, False) fails (error 87, invalid argument) on > standard streams (0, 1, 2) and copies of the standard streams (created > by os.dup()). I have been advocating for that, but I now realize that special-casing these three descriptors in a myriad of fd-creating functions isn't very attractive. (if a standard stream fd has been closed, any fd-creating function can re-create that fd: including socket.socket(), etc.) So perhaps only the *original* standard streams should be left inheritable? The Windows error is a bit more worrying: will it bubble up to Python code when set_inheritable(fd, False) is called implicitly by a fd-creating function? Should set_inheritable() be best effort and silence that error? Regards Antoine. _______________________________________________ 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
