From: Jeremy Henty <jeremy@...>
Date: 2002-12-13T16:09:12+09:00
Subject: Re: Ruby BUG when using PStore and fork

In article <1039475291.072573.1121.nullmailer@picachu.netlab.jp>,
Yukihiro Matsumoto wrote:

> In message "Ruby BUG when using PStore and fork"
>     on 02/12/10, Jeremy Henty <jeremy@chaos.org.uk> writes:
> 
>|PStore does not appear to play well with fork.  

Update: it is nothing to do with PStore really.  The problem is throw
(which PStore uses to implement abort).

#!/usr/bin/env ruby

catch :foo do
  fork do
    throw :foo
  end
  Process.wait
  exit
end

foo.rb:5: [BUG] Unknown longjmp s\tatus 7
ruby 1.6.7 (2002-03-01) [i586-linux]

>  Ah, you can't.  "fork" creates copy of the process.  Copied child
> process cannot affect the parent process.  How can we abort
> transaction from the child process.

Well, I didn't really *want* to abort the transaction.  I just wanted
the child to lose the lock on the pstore file.  I was sort of
*relying* on the isolation of the child from the parent to get away
with calling abort in the child without anything happening in the
parent.  Perhaps this is my just reward for trying such a dirty trick!
:-)

If I comment out "file.flock(File::LOCK_EX)" in pstore.rb then things
work as I would like.  But I don't want to lose the protection of
locking for all pstore applications.  I suspect the right thing to do
is to fork before opening the pstore and use IPC to tell the child to
spawn browsers.  I had hoped to avoid such complications, but maybe I
should bite the bullet this time.  Unless someone has a better
solution?

Regards, 

Jeremy Henty