Charles-François Natali 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.
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18756> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
