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 <CAH_1eM0dFWCCmoi6tZW6U1eJJ-AL-TKFu6J0LjPkGrbZpwPqXQ@mail.gmail.com>
In-reply-to <1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>
Content
>> 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.
History
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