Message195339
| Author |
vstinner |
| Recipients |
christian.heimes, hynek, tarek, vstinner |
| Date |
2013年08月16日.15:30:57 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1376667057.94.0.579949604711.issue18756@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> I have seen complains from e.g. Tarek that os.urandom() fails under high load: https://twitter.com/tarek_ziade/status/362281268215418880
dev_urandom_python() should handle ENFILE and ENOENT differently to raise a different exception. Or it should always call PyErr_SetFromErrno(PyExc_OSError); ?
Can tarek tell us more about its usecases: is he directly calling os.urandom() or does he use the random module? How many threads?
> How about os.urandom() uses a persistent file descriptor?
os.urandom() is called at Python startup to generate a "secret key" for random hash. If the file descriptor is never closed, the next file descriptor will be 4 instead of the expect 3.
Always keeping an internal file descriptor open may have unexpected effects like leaking a file descriptor to a child process... (see the PEP 446, not implemented yet).
I'm ok to keep a fd open if the user controls the lifetime of the object (lifetime of the fd). For example, I expect that rng = SystemRandom() opens /dev/urandom when the object is created, and closes it when the object is destroyed. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年08月16日 15:30:57 | vstinner | set | recipients:
+ vstinner, christian.heimes, tarek, hynek |
| 2013年08月16日 15:30:57 | vstinner | set | messageid: <1376667057.94.0.579949604711.issue18756@psf.upfronthosting.co.za> |
| 2013年08月16日 15:30:57 | vstinner | link | issue18756 messages |
| 2013年08月16日 15:30:57 | vstinner | create |
|