Message195358
| Author |
neologix |
| Recipients |
christian.heimes, hynek, jcea, neologix, pitrou, tarek, vstinner |
| Date |
2013年08月16日.16:47:14 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<CAH_1eM3OGdFTLJXemgkiKtHDiDmdfVJvLKSsQueOM9nONDFs5A@mail.gmail.com> |
| In-reply-to |
<1376671082.1.0.874272119893.issue18756@psf.upfronthosting.co.za> |
| Content |
> I do many calls on urandom() so that's the FD bottleneck.
>
>> So os.urandom() isn't your biggest problem here.
>
> Of course it is. But it looks like you know better without having looked at
> the code. :)
So please explain me :-)
os.urandom() can only be called by one thread/greenlet at a time.
So I assumed you're using a per-client thread/greenlet, and so a
per-client socket. So, you have O(N) open sockets, which are
long-lived. OTOH, you can only have so many threads inside
os.urandom() at a time, since it's short lived, and the FD is closed
as soon as urandom() returns. So I would assume that you have
asymptotically at least as many open sockets than FDs open to
os.urandom.
>> I'd suggest you to just open '/dev/urandom' once,
>> and then make all your threads/green-threads read from it.
>
> Let me know how to do this without being able to prevent the API to close
> the FD everytime.
Simply open('/dev/urandom', 'rb').
>> IMO os.urandom() is a really poor API ;-)
>
> Then we should improve it or deprecate it.
I don't think it can be fixed. I think Christian's working on a PEP
for random number generators, which would probably make it easier,
although I din't have a look at it. |
|