> About your example: I'm not sure that it is reliable/portable. I sa > daemon libraries closing *all* file descriptors and then expecting new > file descriptors to become 0, 1 and 2. Your example is different > because w is still open. On Windows, I have seen cases with only fd 0, > 1, 2 open, and the next open() call gives the fd 10 or 13...
Well, my example uses fork(), so obviously doesn't apply to Windows. It's perfectly safe on Unix. > I'm optimistic and I expect that most Python applications and > libraries already use the subprocess module. The subprocess module > closes all file descriptors (except 0, 1, 2) since Python 3.2. > Developers relying on the FD inheritance and using the subprocess with > Python 3.2 or later already had to use the pass_fds parameter. As long as the PEP makes it clear that this breaks backward compatibility, that's fine. IMO the risk of breakage outweights the modicum benefit. > The subprocess module has still a (minor?) race condition in the child > process. Another C thread can create a new file descriptor after the > subprocess module closed all file descriptors and before exec(). I > hope that it is very unlikely, but it can happen. No it can't, because after fork(), there's only one thread. It's perfectly safe. cf _______________________________________________ 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
