[Python-Dev] PEP 446 (make FD non inheritable) ready for a final review (original) (raw)

Charles-François Natali cf.natali at gmail.com
Fri Aug 23 22:30:23 CEST 2013

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 passfds 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

More information about the Python-Dev mailing list