Project

General

Profile

Actions

Feature #6844

closed

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

Added by andrewhavens (Andrew Havens) over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:47079]

Description

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!

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0