Message 195348 - Python tracker

➜

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	tarek
Recipients	christian.heimes, hynek, jcea, neologix, pitrou, tarek, vstinner
Date	2013-08-16.16:19:12
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>
In-reply-to

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. 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 ? Opening an FD on every call sounds under optimal, I am not seeing any drawback not to try to optimize that API.

> 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.

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 ?

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

History
Date	User	Action	Args
2013-08-16 16:19:12	tarek	set	recipients: + tarek, jcea, pitrou, vstinner, christian.heimes, neologix, hynek
2013-08-16 16:19:12	tarek	set	messageid: <1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za>
2013-08-16 16:19:12	tarek	link	issue18756 messages
2013-08-16 16:19:12	tarek	create