On 17 May 2016 at 20:37, André Warnier <a...@ice-sa.com> wrote: > On 17.05.2016 20:26, demerphq wrote: >> >> On 17 May 2016 at 20:23, demerphq <demer...@gmail.com> wrote: >>> >>> On 16 May 2016 at 20:03, Bruce Johnson <john...@pharmacy.arizona.edu> >>> wrote: >>>> >>>> >>>>> On May 16, 2016, at 10:15 AM, André Warnier (tomcat) <a...@ice-sa.com> >>>>> wrote: >>>>> >>>>> >>>>> join "", map +(0..9,"a".."z","A".."Z")[rand(10+26*2)], 1..32 ; >>>>> >>>>> looks at first sight to me like quite inefficient and probably likely >>>>> to generate the same string regularly, even if it does not look that way. >>>>> (The only variable there is rand(), and it can only return values >>>>> between 0 and 62). >>>> >>>> >>>> The function is meant to map a random element from the 62-element-long >>>> array (0..9,"a".."z","A".."Z”) (hence a rand() call to generate a number >>>> from 0 and 62), 32 times, and join them into a string. >>>> >>>> Although I think that should really be rand(9+26*2) to properly generate >>>> array indices for the entire array and no more. With a number between 0 and >>>> 62 (63 numbers) and a 62-element array, you’ll be retrieving nulls from the >>>> array 1/62 calls, but all that means is that the string is one char >>>> shorter >>>> for each time '62’ comes up... >>>> >>>> So long as rand is properly seeded, you should not get repeats, at least >>>> not frequently enough to ever notice, I’d think. >>>> >>>> This is textbook Perl, as in I’m pretty sure it’s out of one of Larry >>>> Wall’s books; I use it to generate random strings for cookies. >>>> >>>> If it’s properly seeded in the original code, it should either work or >>>> not work on all five servers. Not working on one out of the five makes me >>>> think maybe there’s some sort of weird caching issue. >>> >>> >>> Or for some reason one of the servers goes through a code path where >>> it calls srand/rand prefork. >>> >>> An unfortunate side effect of the rules of srand in perl is that if >>> you fork without calling rand each child process will have their own >>> seed. if you rand before fork then all the children will have their >>> own seed. >> >> >> Sorry, that should read "if you rand before fork then all the children >> will SHARE THE SAME SEED". >> >> I personally consider this a bug in Perl, but I doubt it will get fixed. >> > > I think that the children will share the same seed in any case. (That sounds > kind of biblical..). > The point is, all children have initially a copy of the same pristine perl > interpreter, and the initial grand-father seed (to the initial srand()) is > in there somewhere. > Only if each child starts by an srand($my-own-unique-seed), will they > subsequently get a different sequence of rand() responses.
No. Perl has a flag internally that says if srand has been called prior to use of rand. If you fork before you call (s)rand then each child process will have their own copy of the flag, which will be false, and thus will cause srand() to be called in the subprocess properly. This is easily verified without needing to know the source (which I do): ml905401:~ yorton$ perl -le'fork; print rand' 0.96367916867985 0.404761314931424 ml905401:~ yorton$ perl -le'rand; fork; print rand' 0.716089713943319 0.716089713943319 -- perl -Mre=debug -e "/just|another|perl|hacker/"
