[ruby-core:24516] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

Lee Hinman wrote:
> On Jul 21, 2009, at 9:06 PM, Vanja Bucic wrote:
>> Issue #1525 has been updated by Vanja Bucic.
>>
>>
>> Just to chime in on this issue.
>>
>> It is affecting our company as well. We run our software on apple 
>> machines in a server environment.
>> Our application is a multithreaded daemon process that is accessing 
>> mysql database pretty often. Some of these threads fork off a task 
>> that may take some time to complete. It has worked well prior to ruby 
>> 1.9.  Since then we have tried to find a workaround but to no avail. 
>> Any attempts to use fork in our application will result in deadlocks 
>> 8/10 times.
>> It deadlocks in weirdest places, like 'puts'  or mysql.query (which 
>> we know is setting global lock internally, but should be thread safe).
>>
>> Any ideas and attempts to resolve this ASAP are welcome.
>
> I ran into this issue a while back trying to fix the forkoff library 
> for Ruby 1.9.1. I too would like to know what's causing it, I was 
> wondering if the error man pertain to this (from the fork man page):
>
> "A process shall be created with a single thread. If a multi-threaded 
> process calls fork(), the new process shall contain a replica of the 
> calling thread and its entire address space, possibly including the 
> states of mutexes and other resources. Consequently, to avoid errors, 
> the child process may only execute async-signal-safe operations until 
> such time as one of the exec functions is called. Fork handlers may be 
> established by means of the pthread_atfork() function in order to 
> maintain application invariants across fork() calls."
>
> Hopefully someone more familiar with Ruby internals may know what's 
> causing it. Anyone?
>
> - Lee
>
Yes. As you mentioned, this bug related to inappropriate usage of 
non-async-signal-safe functions in a forked child process. And this is a 
already known issue which has been reported on BSD systems.

(Let's call it a *issue* but not a *bug* because this is the 
specification of pthread.)

Because users are free to do anything in a forked child process through 
Ruby's interface, it is hard to avoid this kind of error by Ruby 
interpreter. However, the developer are trying to reduce the chance of 
this kind of error by postponing internal thread generation.

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