2010/1/17 Benson Margulies <bimargul...@gmail.com>:
> On Sun, Jan 17, 2010 at 7:31 AM, Sean Owen <sro...@gmail.com> wrote:
>> But does that affect code which instantiates a MersenneTwisterRNG with
>> its own seed?
>
> That's what it looked like to me, but I may have been depending on
> Olivier's analysis.
I confirm that the first call to the java.security.SecureRandom
constructor (which is in the static part of uncommons math init) does
two system calls to /dev/random:
$ strace -o /tmp/clj.strace.out -F -f java $JAVA_OPTS \
-cp .:..:/usr/share/java/jline.jar:$LIBS \
jline.ConsoleRunner clojure.lang.Repl
user=> (java.security.SecureRandom.)
#<SecureRandom java.security.secureran...@1cffeb4>
user=> (java.security.SecureRandom.)
#<SecureRandom java.security.secureran...@1cd107f>
while in a separate console:
$ tail -f /tmp/clj.strace.out | grep "/dev/random"
18354 stat64("/dev/random", {st_mode=S_IFCHR|0666, st_rdev=makedev(1,
8), ...}) = 0
18354 open("/dev/random", O_RDONLY|O_LARGEFILE) = 19
Further calls to the constructor or the generateSeed reuse the same
file descriptor (no further calls to open on /dev/random).
I can instantiate many (100000) SecureRandom instances without
blocking the process while calling generateSeed actually consume
entropy as expected and blocks the app after a couple of hundred
bytes.
In our case it is possible that only the first call to the
SecureRandom constructor in each forked tests is enough to block
slowdown them all even if we don't call generateSeed.
--
Olivier
http://twitter.com/ogrisel - http://code.oliviergrisel.name
