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

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


More information about the Python-Dev mailing list