From: Eric Wong <normalperson@...>
Date: 2009-07-28T19:34:02+09:00
Subject: [ruby-core:24585] Re: [Bug #1525] Deadlock in Ruby 1.9's VM	caused by ConditionVariable.wait and fork?

"none <" <tetsu.soh.dev@gmail.com> wrote:
> Eric Wong wrote:
>> It should be possible to fix the problem by keeping track of all mutexes as
>> they're created/initialized and registering pthread_atfork handlers
>> to ensure all mutexes are unlocked when the child starts running.
>>   
> In fact, it is impossible to track all mutexes because the usage of  
> mutexes really
> depends on the underlying implementation.
> For example, the deadlock on this issues doesn't happen on Linux system,  
> even
> not on FreeBSD7.2, but happens on FreeBSD6.4.

Yes, it's not easy; but I think we can start making a best effort and
wait for OSes to catch up.  This lets us start paving the way towards
reducing the reliance on the GVL:

The big system-side offenders are stdio, malloc and resolver...

1. Ruby 1.9 already removed most of stdio dependencies.

2. malloc still happens under a GVL, but I think replacing it with a
Ruby-aware memory allocator that's better integrated with the GC and
thread management would be a good thing anyways.

3. Maybe look at c-ares or even resolv.rb since they'd play nicer
with timeouts anyways... (not too sure on this one).

There's probably a few other things, but I think those are the main
ones that server applications (the ones most likely to use threads+fork)
will care about...

-- 
Eric Wong