Random.rand() requires pre-seeding in forked process
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 Random.new.rand().
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: http://rubyforge.org/tracker/index.php?func=detail&aid=29627&group_id=524&atid=2086
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 Random.new.rand() 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!
Updated by normalperson (Eric Wong) over 8 years ago
"andrewhavens (Andrew Havens)" email@example.com wrote:
Author: andrewhavens (Andrew Havens)
Which version of Ruby are you experiencing this with?
It should be fixed in the latest 1.9.3 and 1.8.7 releases