Message195351
| Author |
christian.heimes |
| Recipients |
christian.heimes, hynek, jcea, neologix, pitrou, tarek, vstinner |
| Date |
2013年08月16日.16:26:19 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<520E52AA.5090208@cheimes.de> |
| In-reply-to |
<1376669952.75.0.874930027417.issue18756@psf.upfronthosting.co.za> |
| Content |
> Tarek Ziadé added the comment:
>
>> 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 highly unlikely that you are every going to exhaust the CPRNG to a
point were it is no longer cryptographically secure. Thomas Ptacek
pointed me to http://security.stackexchange.com/a/3939 yesterday.
>> 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.
The drawback is a slightly more complicated implementation that has to
deal with invalid FDs. |
|