From: John Carter <john.carter@...>
Date: 2008-10-07T04:59:01+09:00
Subject: Re: Ruby lacks atfork : The evil that lives in fork...

--Boundary_(ID_LQHzweM6DnnxPrLDMV3+Jw)
Content-type: TEXT/PLAIN; format=flowed; charset=utf-8
Content-transfer-encoding: QUOTED-PRINTABLE

On Tue, 7 Oct 2008, Brian Candler wrote:

> John Carter wrote:
>> From the fork man page...
>>
>>         * The child process is created with a single thread =E2=
=80=94 the one
>>           that called fork().
>
> That manpage is talking about OS threads, not Ruby threads.

Correct. But I had just demonstrated that the problem pthread_atfork
was designed to solve exists within ruby threads.

> According to ri, when (Ruby's) fork is called only the currently-ru=
nning
> (Ruby) thread continues to live in the child process.

Exactly the same as with pthreads and linux fork.

>>           The entire virtual address space of
>>           the parent is replicated in the child, including the sta=
tes
>>           of mutexes, condition variables, and other pthreads obje=
cts;
>
> This is talking about OS mutexes etc. Again, the Ruby objects with
> corresponding names are entirely different.

That is neither here not there. The point is I have just shown that
problem described exists within in Ruby.

ie. If deep within a library routine there is are threads and mutexes
and deep within another library routine there is a Process.fork the
potential for "the wrong thing" to happen exists.

Where the wrong thing is that :- if a thread is in the critical
section protected by the mutex, it may leave it an inconsistent and
unusable state when the "fork" is executed by another thread.

If the child process ever invokes the library with the mutex, it may
find the Mutex unlocked, when it should be locked, and hence enter a
critical section, when it shouldn't, and find an inconsistent state
which leads to an erroneous result.

The solution proposed by POSIX is to provide the facility for
libraries to chain handlers, to handle in some sensible fashion, any
fork event occurring in a different library.

If Ruby can come up with a better mechanism than atfork to handle thi=
s
problem, I would be very pleased.

But some solution is required to be able to have reusable multiple
libraries some of which use sub-processes, some which use threads.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.n=
z
New Zealand

--Boundary_(ID_LQHzweM6DnnxPrLDMV3+Jw)--