From: Lee Hinman <matthew.hinman@...>
Date: 2009-06-24T01:24:28+09:00
Subject: Re: Threads + Forks in Ruby 1.9.1p129

On Tue, Jun 23, 2009 at 10:14 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
>
> Lee Hinman wrote:
> > Hey All,
> > I'm seeing some weirdness trying to get Ara's forkoff gem working on
> > ruby 1.9.1.
>
> Maybe it doesn't copy the threads over right or something?
> http://ruby-doc.faithpromotingstories.org/doc/ruby-1.9.1-p129/classes/Kernel.html#M002828
> seems to say that "threads are not copied" or something [?]

I'm wondering if this text might have something to do with it (from
the fork man page,
http://www.opengroup.org/onlinepubs/000095399/functions/fork.html ):

"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.
When the application calls fork() from a signal handler and any of the
fork handlers registered by pthread_atfork() calls a function that is
not asynch-signal-safe, the behavior is undefined."

The line "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"
seems to be important to this issue, however I'm not familiar enough
with Ruby's internals to understand how this would cause the
deadlock/hanging, does anyone have any ideas?

- Lee