This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dstufft
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.18:40:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> As a final note, let me steer you towards this comment in Python/random.c:
> /* Issue #25003: Don' use getentropy() on Solaris (available since
>  * Solaris 11.3), it is blocking whereas os.urandom() should not block. */
> Yes: we already had this discussion for Solaris, nine months ago, on issue #25003.  Both Guido and Tim Peters were involved in the discussion.  The decision there: use lower-quality random bits to seed the MT when importing the random module.  Keeping the slowdown was so obviously wrong it wasn't even debated.

I will point out, that was a somewhat different situation as ``getentropy`` on Solaris is more like /dev/random in that it tries to decide how much random-ness is in the pool and will randomly block throughout the execution of the program. The ``getrandom()`` call on Linux (and Solaris) will, by default, only block on the first boot at the very beginning before the kernel has collected enough entropy.

I don't think this changes anything, I just want to be clear because there are two kinds of "blocking" in this discussion, one that only occurs in very specific scenarios and one that occurs regularly in the operation of the program.
Date User Action Args
2016-06-07 18:40:30dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 18:40:30dstufftsetmessageid: <>
2016-06-07 18:40:30dstufftlinkissue26839 messages
2016-06-07 18:40:30dstufftcreate