Feature #6844

Random.rand() requires pre-seeding in forked process

Added by andrewhavens (Andrew Havens) almost 8 years ago. Updated over 7 years ago.

Target version:


I'm submitting this as a feature because I'm not sure if this implementation is intentional.

While using the delayed job gem and the daemons gem, I recently came across a segmentation fault. It was relatively hard to track down because it was happening in a background process. I finally tracked down the line in the code that was causing the segmentation fault: Random.rand(). However, it works when you do

After digging through the source of the daemons gem, I found the real cause of the problem. The way daemons works is that it forks a new child process to run your code, saves the child pid so you can find it later, then kills the parent process. When the child process is spawned, it needs to seed the random number generator by calling srand(). So I patched that function and submitted it to the daemons project:

So my question/feature request is the following:

Is there a way we can avoid the srand() step by having ruby do this part for us? Maybe by calling Random.rand() it checks to see if it has been seeded already. The weird thing is that works as well as rand() (which is Kernel.rand). So something is different about Random.rand() that makes the srand() step necessary.

Thanks! Keep up the great work!

Also available in: Atom PDF