> 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.