iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 522: *BSD behaviour is variant specific

This commit is contained in:
Nick Coghlan 2016-06-21 18:17:54 -07:00
parent b819c243a3
commit 914dfa153e
1 changed files with 11 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
pep-0522.txt
View File

@ -132,12 +132,13 @@ unfortunately the exact conditions that trigger this are difficult to predict,
and when it occurs then there is no direct way for userspace to tell it has
happened without querying operating system specific interfaces.
On \*BSD systems, encountering this situation means ``os.urandom()`` will block
waiting for the system random number generator to be ready - the associated
On \*BSD systems (if the particular \*BSD variant allows the problem to occur
at all), encountering this situation means ``os.urandom()`` will either block
waiting for the system random number generator to be ready (the associated
symptom would be for the affected script to pause unexpectedly on the first
call to ``os.urandom()``.
call to ``os.urandom()``) or else will behave the same way as it does on Linux.
However, on Linux, in Python versions up to and including Python 3.4, and in
On Linux, in Python versions up to and including Python 3.4, and in
Python 3.5 maintenance versions following Python 3.5.2, there's no clear
indicator to developers that their software may not be working as expected
when run early in the Linux boot process, or on hardware without good
@ -216,9 +217,11 @@ As no changes are proposed for operating systems other than Linux,
``os.urandom()`` retains its existing behaviour as a nominally blocking API
that is non-blocking in practice due to the difficulty of scheduling Python
code to run before the operating system random number generator is ready. We
believe it may be possible on \*BSD, but nobody has explicitly demonstrated
that. On Mac OS X and Windows, it appears to be straight up impossible to
even try to run a Python interpreter that early in the boot process.
believe it may be possible to encounter problems akin to those described in
this PEP on at least some \*BSD variants, but nobody has explicitly
demonstrated that. On Mac OS X and Windows, it appears to be straight up
impossible to even try to run a Python interpreter that early in the boot
process.
On Linux, ``os.urandom()`` retains its status as a guaranteed non-blocking API.
However, the means of achieving that status changes in the specific case of
@ -242,7 +245,7 @@ regardless of whether or not they perform security sensitive operations:
- applications that are only run after the system RNG is ready
Applications in this category simply won't encounter the new exception, so it
will be reasonable for developers to simply wait and see if they receive
will be reasonable for developers to wait and see if they receive
Python 3.6 compatibility bugs related to the new runtime behaviour, rather than
attempting to pre-emptively determine whether or not they're affected.