Charles-Francois Natali <neolo...@free.fr> added the comment:
> Martin v. Löwis <mar...@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:
---
import os
d = os.open('/dev/urandom', os.O_RDONLY)
data = os.read(d, 1 << 28)
os.close(d)
print('read %d bytes' % len(data))
---
and in another terminal
pkill -STOP -xn python
then
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.
Cheers
> ----------
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue10824>
> _______________________________________
>
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10824>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
