Email list hosting service & mailing list manager

continuations and threads Jim Blandy (18 Feb 2000 00:40 UTC)
Re: continuations and threads Marc Feeley (18 Feb 2000 05:06 UTC)
Re: continuations and threads Jim Blandy (18 Feb 2000 17:11 UTC)
Re: continuations and threads sperber@xxxxxx (21 Feb 2000 08:15 UTC)

Re: continuations and threads sperber@xxxxxx 21 Feb 2000 08:15 UTC

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

>> > I think this is pretty gross, but it does allow a natural
>> > correspondence between C function calls and Scheme function calls:
>> > continuations preserve active calls to C functions, as well as Scheme
>> > functions.  If it's important to your users to be able to write C
>> > functions that can call and be called by Scheme functions, I think
>> > this is a plausible implementation choice.  I'm not aware of any other
>> > implementation that does this while requiring so little distortion of
>> > your C code.  (But if you know of one, I'd love to hear about it!)
>>
>> There is another way (I have not implemented it yet though)... but it
>> is too complex to describe at this hour of the night!

Jim> :)

Jim> Now that you mention it, there is something I remember Roland McGrath
Jim> implementing for SMLNJ, while working for Olin Shivers.

Jim> I think the basic idea was that frames (activation records) for ML
Jim> functions were kept on the heap (as normal), while frames for C
Jim> functions were kept on a C stack.  You let the ML frames behave like
Jim> the first-class objects they are --- you can call/cc to your heart's
Jim> content --- but if you try to return to a C frame in a non-stacklike
Jim> order, the ML/C boundary code detects this and throws an exception.

Jim> I think he even arranged it so that if you returned early to an older
Jim> C frame, the younger frames would be popped appropriately (via
Jim> longjmp), and any references to younger C frames would be marked
Jim> invalid, so you'd get an error if you tried to use them.

The C FFI Richard Kelsey and I implemented for Scheme 48 does this as
well.  Here's the relevant blurb from the documentation:

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

   In Scheme 48 threads are implemented using continuations, so the
   downward restriction applies to them as well. An attempt to return
   from Scheme to C at a time when the appropriate C frame is not on top
   of the C stack will cause the current thread to block until the frame
   is available. For example, suppose thread t0 calls a C procedure which
   calls back to Scheme, at which point control switches to thread t1,
   which also calls C and then back to Scheme. At this point both t0 and
   t1 have active calls to C on the C stack, with t1's C frame above
   t0's. If thread t0 attempts to return from Scheme to C it will block,
   as its frame is not accessable. Once t1 has returned to C and from
   there to Scheme, t0 will be able to resume. The return to Scheme is
   required because context switches can only occur while C code is
   running. T0 will also be able to resume if t1 uses a continuation to
   throw past its call to C.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla