This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients ferringb, gregory.p.smith, jyasskin, loewis, nadeem.vawda, neologix, pitrou, rosslagerwall, s7v7nislands, vstinner
Date 2012-01-15.11:09:50
SpamBayes Score 3.1544953e-09
Marked as misclassified No
Message-id <CAH_1eM0AU9f80e_g6L8X9p-BmYnV3-a0jECz6XOyRvwfrbULGQ@mail.gmail.com>
In-reply-to <1326622646.58.0.214299064907.issue8052@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2012-01-15 11:09:52neologixsetrecipients: + neologix, loewis, gregory.p.smith, pitrou, vstinner, ferringb, jyasskin, nadeem.vawda, s7v7nislands, rosslagerwall
2012-01-15 11:09:51neologixlinkissue8052 messages
2012-01-15 11:09:50neologixcreate