From: ctm@... (Clifford T. Matthews)
Date: 2006-09-29T08:44:49+09:00
Subject: Re: continuations across fork?

>>>>> "Gary" == gwtmp  <gwtmp01@mac.com> writes:

    Gary> On Sep 28, 2006, at 4:49 PM, Keith Gaughan wrote:

    >> On Fri, Sep 29, 2006 at 02:10:52AM +0900, Clifford T. Matthews
    >> wrote: Probably because you're attemptin to jumP to part of a
    >> completely different process. Program counters can't jump
    >> between processes like that.

    Gary> I don't think he is trying to initiate a continuation in the
    Gary> child from the parent or vice versa (right Clifford?). If
    Gary> you create a continuation before the fork, and then fork,
    Gary> both the parent and the child process will have duplicate
    Gary> copies of the continuation.  You've cloned the process and
    Gary> everything inside it including the continuations.

Right.

    Gary> Having the child resume its continuation or the parent
    Gary> resume its continuation should be ok. I'm surprised that it
    Gary> didn't work.  It is either an oversight or something about
    Gary> the way Ruby implements fork (exceptions or IO?), but I
    Gary> don't think it is an inherent problem in the concept.

OK, since nobody has pointed out something obvious, I'll ask on
ruby-core tomorrow.  The portion of ruby that disallows the call is
the second if statement (from eval.c):

static VALUE
rb_cont_call(argc, argv, cont)
    int argc;
    VALUE *argv;
    VALUE cont;
{
    rb_thread_t th = rb_thread_check(cont);

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

Presumably there's a reason why that second check is there, but I'm
not sufficiently versed in Ruby internals to know why.  It's quite
possible that a different check could be used that would allow my use
of continuations but still disallow whatever bad thing the current
check is designed to catch.

-- 
Cliff Matthews <ctm@ardi.com>