From: "none <" <tetsu.soh.dev@...>
Date: 2009-07-26T12:05:18+09:00
Subject: [ruby-core:24563] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

Vanja Bucic wrote:
> Issue #1525 has been updated by Vanja Bucic.
>
>
> In Reply to:
> -- IMHO, from the respective of user, although it is hard, try not to use
> -- any non-async-signal-safe functions in a forked child process before any
> -- exec functions are called.
>
> -- - Tetsu
>
> Just so I can understand the logic, could you rewrite my test case above so that it does not deadlock?
> I am not clear which of the functions I used in the test case are non-async-signal-safe or not.
>
> Thanks.
> ----------------------------------------
> http://redmine.ruby-lang.org/issues/show/1525
>
> ----------------------------------------
> http://redmine.ruby-lang.org
>
>   
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


Thanks.
-Tetsu