I think I must be missing something --
We don't use SecureRandom directly, so what would these effects have
to do with slow unit tests in our project?
And also am I right that, if we use our own seed in
MersenneTwisterRNG, we still get deterministic behavior?
I'm going to change all our tests to make sure we use a fixed seed,
and I'm still not clear why this wouldn't address the randomness
issue?
I don't know about performance, why this would have a bearing or why
it's recently slowed. Is that the issue you guys are looking at?
On Sun, Jan 17, 2010 at 1:11 PM, Olivier Grisel
<olivier.gri...@ensta.org> wrote:
> 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
>
