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 alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, josh.r, ncoghlan, neologix, tshepang
Date 2014-04-28.13:34:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> Using os.urandom is the *right* thing to do for getting random in an application, but the current implementation effectively punishes people who use it if their application is highly concurrent.

And I argue that this scenario is almost as likely as the one you
depict above: we never had a bug report before, and if you have a look
at the the bug report which led to the change in question, it's not
clear at all that all threads were indeed reading from /dev/urandom
when EMFILE was raised. Since reading from /dev/urandom shouldn't
block, it's not clear at all how a realistic workload would actually
hit the file descriptor limit because RLIMIT_NOFILE threads are
reading from /dev/urandom.

But don't get me wrong, I'm not saying this change is useless, it
actually makes sense to use a persistent FD. But backporting always
has a risk, which has to be balanced.
Date User Action Args
2014-04-28 13:34:01neologixsetrecipients: + neologix, ncoghlan, janssen, giampaolo.rodola, christian.heimes, benjamin.peterson, alex, tshepang, dstufft, josh.r
2014-04-28 13:34:01neologixlinkissue21305 messages
2014-04-28 13:34:01neologixcreate