From: Stanislav Sedov <stas@...>
Date: 2009-09-29T20:01:13+09:00
Subject: [ruby-core:25839] Re: [Bug #1525] Deadlock in Ruby 1.9's VM caused  by ConditionVariable.wait and fork?

On Thu, 23 Jul 2009 11:12:33 +0900
"none <" <tetsu.soh.dev@gmail.com> mentioned:

> >
> 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.
> 

It's generally hard to guarantee this as in the ruby application you don't
have the full contol on the code executed.  non-async-signal-safe functions
in the POSIX language means everything except syscalls, so calling malloc/free
or other libc functions can be very dangerous.  Some of them are very hard to
avoid.

Is it possible to implement fork in a way that it will call exec on the ruby
interpreter just after forking passing the block to be runned via command
libe arguments or by a pipe?  This way it will behave consistently and safely
in all POSIX-compliant systems and should have no negative effects.

-- 
Stanislav Sedov
ST4096-RIPE