From: Lee Hinman <matthew.hinman@...>
Date: 2009-07-22T14:14:49+09:00
Subject: [ruby-core:24492] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?

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