From: ctm@... (Clifford T. Matthews)
Date: 2006-09-29T06:10:58+09:00
Subject: Re: continuations across fork?

>>>>> "Keith" == Keith Gaughan <kmgaughan@eircom.net> writes:

    Keith> On Fri, Sep 29, 2006 at 02:10:52AM +0900, Clifford
    Keith> T. Matthews wrote:
    >> I wrote some code that deliberately uses continuations that
    >> cross a fork boundary.  When I went to test it, I was surprised
    >> by the error: "continuation called across trap".  I can think
    >> of a few reasons why people might not want to use continuations
    >> across fork, but not knowing Ruby internals particularly well,
    >> I couldn't see a reason why it should be absolutely prohibited.

    Keith> Probably because you're attemptin to jumP to part of a
    Keith> completely different process. Program counters can't jump
    Keith> between processes like that.

Thanks for the reply.

I can't speak for the other operating systems, but I'm fairly familiar
with UNIX and Linux:

FORK(2)                    Linux Programmer�s Manual                   FORK(2)
...
       fork()  creates  a  child  process that differs from the parent process
       only in its PID and PPID, and in the fact  that  resource  utilizations
       are set to 0.  File locks and pending signals are not inherited.
...

Of course that's the fork system call and not the Ruby fork
implementation.  However, in my use of continuations across fork,
there was no problem with the PC.  My code ran fine, did exactly what
I expected it to do with the results I wanted.  All I had to do was
disable the check in eval.c:

    if (th->thgroup != cont_protect) {
	rb_raise(rb_eRuntimeError, "continuation called across trap");
    }

In general, I'm relatively aware of memory layout, assembler,
interpreters, etc.  In a previous life I did some non-trivial work in
emulation and reverse-engineering.  That doesn't preclude me from
overlooking the obvious, so if you still think I'm mistaken and can
elaborate on "Program counters can't jump between processes like
that," I'll listen.

-- 
Cliff Matthews <ctm@ardi.com>