iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 446: clarify impact on performances of the PEP 

It is not always possible to set close_fds to False, when this PEP makes it
safe in some cases.
This commit is contained in:
Victor Stinner 2013-08-27 22:21:31 +02:00
parent fbeac3a6e1
commit 458823f410
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
pep-0446.txt
View File

@ -539,10 +539,14 @@ safe to use subprocess with the *close_fds* parameter set to ``False``.
Not closing explicitly file descriptors is faster, especially on
platform with a large maximum number of file descriptors.
The default value of the *close_fds* parameter is unchanged, because
third party modules, especially extensions implemented in C, may not
conform immediatly to the PEP 446 (still create inheritable file
descriptors).
The default value of the *close_fds* parameter of the ``subprocess``
module is unchanged, file descriptors and handles are still closed
explicitly on UNIX. Third party modules, especially extensions
implemented in C, can still create inheritable file descriptors and
handles. But with this PEP, it becomes safe to set *close_fds* to
``False`` when all file descriptors and handles are created
non-inheritable, which is faster on UNIX when the maximum number of file
descriptors is large.
Backward Compatibility