Email list hosting service & mailing list manager


Re: continuations and threads sperber@xxxxxx 26 Feb 2000 16:08 UTC

>>>>> "Jim" == Jim Blandy <xxxxxx@red-bean.com> writes:

Mike> The C FFI Richard Kelsey and I implemented for Scheme 48 does this as
Mike> well.  Here's the relevant blurb from the documentation:
Mike>
Mike> There are some complications that occur when mixing calls from C to
Mike> Scheme with continuations and threads. C only supports downward
Mike> continuations (via longjmp()). Scheme continuations that capture a
Mike> portion of the C stack have to follow the same restriction. For
Mike> example, suppose Scheme procedure s0 captures continuation a and
Mike> then calls C procedure c0, which in turn calls Scheme procedure s1.
Mike> Procedure s1 can safely call the continuation a, because that is a
Mike> downward use. When a is called Scheme 48 will remove the portion of
Mike> the C stack used by the call to c0. On the other hand, if s1
Mike> captures a continuation, that continuation cannot be used from s0,
Mike> because by the time control returns to s0 the C stack used by c0
Mike> will no longer be valid. An attempt to invoke an upward
Mike> continuation that is closed over a portion of the C stack will
Mike> raise an exception.

Jim> Actually, this is less powerful than what I described.  In Roland's
Jim> system, you don't need to unwind the C stack when s1 invokes a.  You
Jim> only need to unwind the C stack when s0 returns.  If s0 instead
Jim> invokes some continuation b captured by s1, that's fine.

I'm not sure I'm getting what's going on here:  I *want* the C stack
to be unwound (it's a trivial-enough operation), so that the Scheme
heap references in the C activation records get freed---you might
get a space leak otherwise.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla