[issue8052] subprocess close_fds behavior should only close open fds
Charles-François Natali
report at bugs.python.org
Sun Jan 15 12:09:51 CET 2012
Charles-François Natali <neologix at free.fr> added the comment:
> Either way, here's a question: does anyone actually know of a unix that does procfs, and has a daft opendir implementation as described below? Aka, are we actually worrying about something relevant, or just hypotheticals?
I think it's more theoretical.
Since dirent have per-struct locks, the only reason why
opendir/readdir would not be async-safe would be because malloc() is
not async-safe. Since we already allow running Python code after
fork(), we implicitely assume that malloc() (and actually most of the
libc) is async-safe, which is true in practice because malloc() uses
pthread_atfork to reset its internal locks after fork().
So IMHO, calling opendir() should be safe (and as noted, many code out
there already does this).
The only question is: do other Unix also have /proc/<pid>/fd? e.g.
FreeBSD, OpenBSD. That's especially important because FreeBSD can have
a huge RLIMIT_NOFILE by default.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8052>
_______________________________________
More information about the Python-bugs-list
mailing list