Larry Hastings added the comment: > Can we please try to be clear about what kind of blocking we mean? > getrandom(flags=0) absolutely *can* block: that's what the original issue was > all about. To ensure it *never* blocks you need to call > getrandom(GRND_NONBLOCK): that's why the flag exists.
Thanks, I was actually confused on this issue. I thought CPython was using getrandom(GRND_RANDOM) and that's why it was blocking. But to be clear, you're right: 3.5.1 is calling getrandom(0) in all circumstances. It never passes in GRND_RANDOM and it never passes in GRND_NOBLOCK. And according to the manpage for getrandom(), getrandom(0) "blocks if the entropy pool has not yet been initialized". What I don't understand is this, from the manpage for urandom: > A read from the /dev/urandom device will not block waiting for more entropy. > If there is not sufficient entropy, a pseudorandom number generator is used > to create the requested bytes. If both sources are right, then /dev/urandom behaves quite differently from getrandom(0). Imagine how confused I was when Theodore Ts'o said: > First of all, if you are OK with reading from /dev/urandom, then you might as > well use getrandom's GRND_NONBLOCK flag. They are logically equivalent. He wrote it. But what he said there doesn't jibe with what the manpages say. Those say that if you call getrandom(GRND_NONBLOCK) before the entropy pool has been initialized, it will return EAGAIN, but any time you read from /dev/urandom you will always get random data. ... the more I learn about this, the less I think I understand it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27266> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
