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

Victor Stinner victor.stinner at gmail.com
Tue Aug 27 00:19:30 CEST 2013


2013/8/26 Guido van Rossum <guido at python.org>:
> I have reviewed the PEP and I think it is good. Thank you so much for
> pushing this topic and for your very thorough review of all the feedback,
> related issues and so on. It is an exemplary PEP!

Thanks :-) I updated the PEP:
http://hg.python.org/peps/rev/edd8250f6893

> I've made a bunch of small edits (mostly to improve grammar slightly, hope
> you don't mind) and committed these to the repo.

Thanks, I'm not a native english speaker, so not problem for such edit.

> https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode437
> pep-0446.txt:437: condition.
> As C-F Natali pointed out, this is not actually a problem, because after
> fork()
> only the main thread survives.  Maybe just delete this paragraph?

Ok, I didn't know that only one thread survives to fork(). (I read
Charles' email, but I forgot to update the PEP.) I simply deleted the
paragraph.

> https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode450
> pep-0446.txt:450: parameter is a non-empty list of file descriptors.
> Well, it could pass closefrom() the max of the given list and manually close
> the
> rest. This would be useful if the system max is large but none of the FDs
> given
> in the list is. (This would be more complex code but it would address the
> issue
> for most programs.)

This was related to the multi-thread issue, which does not exist, so I
also removed this paragraph.

Using closefrom() to optimize subprocess is unrelated to this PEP.

(And yes, the maximum file descriptor can be huge!)

> https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode538
> pep-0446.txt:538: descriptors).
> I would say it should not be changed because the default is still better.
> :-)

(The PEP does not propose to change the default value.)

Under Linux, recent versions of the glibc uses non-inheritable FD for
internal files. Slowly, more and more libraries and programs will do
the same. This PEP is a step in this direction ;-)

Victor


More information about the Python-Dev mailing list