From: Hongli Lai <hongli@...99.net>
Date: 2009-07-26T22:11:41+09:00
Subject: [ruby-core:24565] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

none < wrote:
> Your test code was fine. The deadlock is not caused directly by your
> code but may be related to the timer thread which is  created
> automatically (by ruby processor) after forking a process. And creating
> a native thread (Ruby1.8 was not native threaded, so it is ok.) is not
> async-signal-safe. So deadlock occurs.
> 
> What I mean is that user should try to avoid the following code:
>    fork do
>        Thread.new do   #Bad! Creating native threads is not safe.
>           #some code
>        end
>    end

In my test case, the forked child process does not create any new
threads at all, but still deadlocks.

In any case, not being able to create threads or doing anything
complicated in child processes is a serious limitation. This makes
forking-without-exec in Ruby 1.9 as good as useless. Even
forking-with-exec is dangerous now. For example, suppose that the child
process creates a command string to pass to exec(), and creating this
command string involves malloc()ing memory. Even this isn't safe anymore.

I think Kernel#fork should be made safe as much as possible.