[ruby-core:49749] [ruby-trunk - Feature #6844][Rejected] Random.rand() requires pre-seeding in forked process

Issue #6844 has been updated by mame (Yusuke Endoh).

Status changed from Feedback to Rejected

Likely to be a request based on old version or misconception.  No feedback.  Closing.

-- 
Yusuke Endoh <[e-mail]>
----------------------------------------
Feature #6844: Random.rand() requires pre-seeding in forked process
https://bugs.ruby-lang.org/issues/6844#change-33328

Author: andrewhavens (Andrew Havens)
Status: Rejected
Priority: Normal
Assignee: 
Category: 
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 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!


-- 
http://bugs.ruby-lang.org/