On Dec 2, 2014, at 1:17 PM, Doug Lea <d...@cs.oswego.edu> wrote: > On 12/02/2014 05:02 AM, Paul Sandoz wrote: >> Hi, >> >> Please find below a patch to remove the networking code computing a seed in >> ThreadLocal/SplittableRandom. >> > > Thanks for pushing this through. > (I also adjusted 166 sources accordingly.) > One more touch-up for SplittableRandom is to remove mention > of network interface in internal comments: > > *************** > *** 140,150 **** > * other cases, this split must be performed in a thread-safe > * manner, so we use an AtomicLong to represent the seed rather > * than use an explicit SplittableRandom. To bootstrap the > ! * defaultGen, we start off using a seed based on current time and > ! * network interface address unless the java.util.secureRandomSeed > ! * property is set. This serves as a slimmed-down (and insecure) > ! * variant of SecureRandom that also avoids stalls that may occur > ! * when using /dev/random. > * > * It is a relatively simple matter to apply the basic design here > * to use 128 bit seeds. However, emulating 128bit arithmetic and > --- 139,148 ---- > * other cases, this split must be performed in a thread-safe > * manner, so we use an AtomicLong to represent the seed rather > * than use an explicit SplittableRandom. To bootstrap the > ! * defaultGen, we start off using a seed based on current time > ! * unless the java.util.secureRandomSeed property is set. This > ! * serves as a slimmed-down (and insecure) variant of SecureRandom > ! * that also avoids stalls that may occur when using /dev/random. > * > * It is a relatively simple matter to apply the basic design here > * to use 128 bit seeds. However, emulating 128bit arithmetic and > *************** >
Thanks, updated my copy, Paul.
