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 christian.heimes, hynek, jcea, neologix, pitrou, tarek, vstinner
Date 2013-08-16.16:24:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
>> If os.urandom() doesn't fail, something else will fail soon after.
> the random pool can be exhausted, but this is not "soon after" I think. In
> Linux and Mac OS X, ulimit -n defaults to 512 and 256.

I don't think he's referring to the entropy pool, but to RLIMIT_NOFILE.
You'll likely hit EMFILE sooner or later, e.g. on socket(), open()...

> It's very easy to reach that limit if you write a web app that uses this
> API.
>> I agree with Antoine. Exhausting the FDs is not the problem,
> Do you suggest that we should not use os.urandom on high load ?

What does high load mean?
If you mean many concurrent threads, then you should probably go for
the random module, no?

> Opening an FD on every call sounds under optimal, I am not seeing any
> drawback not to try to optimize that API.

Well, first we'll have to make the code thread-safe, if we want to
keep a persistent FD open. Which means we'll have to add a lock, which
is likely to reduce concurrency, and overall throughput.
Date User Action Args
2013-08-16 16:24:23neologixsetrecipients: + neologix, jcea, pitrou, vstinner, christian.heimes, tarek, hynek
2013-08-16 16:24:23neologixlinkissue18756 messages
2013-08-16 16:24:22neologixcreate