[issue10824] urandom should not block

Martin v. Löwis added the comment: > You'll see that read returns less that 100M bytes when interrupted. I see. > while len(data) < expected: > read(expected - len(data)) > > So we're sure it won't break under some systems/conditions. I think this is not quite the idiom we should use if

[issue10824] urandom should not block

Charles-Francois Natali added the comment: > Martin v. Löwis 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

[issue10824] urandom should not block

Martin v. Löwis 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 th

[issue10824] urandom should not block

Charles-Francois Natali added the comment: > Martin v. Löwis added the comment: > > I wonder why reading from /dev/urandom has a loop in the first place, though > - isn't it guaranteed that you can read as many bytes as you want in one go? > This goes back to #934711, and apparently, even the

[issue10824] urandom should not block

Martin v. Löwis added the comment: Closing it. It seems that people feel more safe when urandom loops until it has enough data (see http://stackoverflow.com/questions/4598507/dev-urandom-maximum-size/4598534#4598534). I might still pursue this idea, but in a different issue. -- statu

[issue10824] urandom should not block

R. David Murray added the comment: Agreed that the original issue is invalid. So either the title should be changed so it can be used to address Martin's question, or it should be closed. -- nosy: +r.david.murray ___ Python tracker

[issue10824] urandom should not block

Martin v. Löwis added the comment: I wonder why reading from /dev/urandom has a loop in the first place, though - isn't it guaranteed that you can read as many bytes as you want in one go? This goes back to #934711, and apparently, even the original patch had the loop - for reasons that got n

[issue10824] urandom should not block

Antoine Pitrou added the comment: > Note that since /dev/urandom is used, with a properly configured > system, this should never block Ok, suggesting closing then. -- resolution: -> invalid status: open -> pending ___ Python tracker

[issue10824] urandom should not block

Michal Čihař added the comment: Yes, it was blocking, but deep in some program (which was actually called by dpkg postinst script), so it took some time to figure out. I don't think it's that fragile to figure out whether it is regular file using os.path.isfile. Indeed it was bug in a system

[issue10824] urandom should not block

Charles-Francois Natali added the comment: >From the documentation: "This function returns random bytes from an OS-specific randomness source." In your case, this problem shows up because of an OS misconfiguration : in that case, the behaviour is undefined (not much Python can do about it). No

[issue10824] urandom should not block

Georg Brandl added the comment: Is it really necessary to do something about this? /dev/urandom being a regular file is clearly a bug in your system configuration, and I don't want to know what all the other programs will do that rely on it... -- nosy: +georg.brandl

[issue10824] urandom should not block

Antoine Pitrou added the comment: > Well in this particular case (/dev/urandom is regular file), it might > make sense to simply raise NotImplementedError IMO it would be quite fragile to try to detect regular files vs special files. I suppose you noticed the issue quite quickly anyway, since y

[issue10824] urandom should not block

Michal Čihař added the comment: Well in this particular case (/dev/urandom is regular file), it might make sense to simply raise NotImplementedError -- ___ Python tracker ___ _

[issue10824] urandom should not block

Antoine Pitrou added the comment: This would change semantics of the library call, though. I see two possible solutions: - do nothing and let users tackle the issue if necessary (e.g. by calling open() themselves and using select() on the resulting fd) - add an optional "blocking" parameter to

[issue10824] urandom should not block

New submission from Michal Čihař : Currently if /dev/urandom does not provide any data, unradom() call is just stuck infinitely waiting for data. I actually faced this issue when /dev/urandom was empty regular file (due to bug in pbuilder, but I don't think it matters how it did happen) and ur