[issue10824] urandom should not block
report at bugs.python.org
Thu Jan 6 09:18:43 CET 2011
Charles-Francois Natali <neologix at free.fr> added the comment:
> Martin v. Löwis <martin at v.loewis.de> added the comment:
>> "It's a bug in random.c that doesn' t check for signal pending inside the
>> read(2) code, so you have no chance to kill the process via signals until
>> the read(2) syscall is finished, and it could take a lot of time before
>> return, if the buffer given to the read syscall is very big..."
>> I've had a quick look at the source code, and indeed, read(2) from
>> /dev/urandom can now be interrupted by a signal, so looping seems to
>> be justified.
> No: if read(2) is interrupted, no data is returned, and exception is
> raised. So it won't loop in that case, but raise the exception out of
> urandom also (which is the right thing to do).
(Sorry for being a little off-topic, but since there's not dedicated thread)
Try with this:
dd if=/dev/urandom of=/dev/null bs=100M count=1
Then, in another terminal:
pkill -USR1 -xn dd
You'll see that read returns less that 100M bytes when interrupted.
You can also try with the following python code:
d = os.open('/dev/urandom', os.O_RDONLY)
data = os.read(d, 1 << 28)
print('read %d bytes' % len(data))
and in another terminal
pkill -STOP -xn python
pkill -CONT -xn python
Same thing, read returns less bytes than requested.
Anyway, since /dev/urandom is not part of any standard (AFAIK), it's
probably better to use the common idiom
while len(data) < expected:
read(expected - len(data))
So we're sure it won't break under some systems/conditions.
> Python tracker <report at bugs.python.org>
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list