Continuations as thread states

Fare Rideau
Thu, 1 May 1997 04:29:06 +0200 (MET DST)

>>: Fare
>: ABW

> On 29 Apr 97 at 1:15, wrote:
Alaric, what have I been telling you all day!

>> First-class Continuations would of course trivialize threads,
>> as well as being of great help to support the Schemists among LispOSers.
It has been reproached that FCC might be difficult to workout efficiently
*on top of a SMP unixish kernel*. Might be true,
though difficult != impossible. If that's the case,
then the LispEnv project might overlook them, if expedient.
Anyway, they're heading full speed towards CommonLISP that has/needs no FCC.
   However, I question even that claim of inefficiency wrt SMP. I really
think FCC is attractive to implement a fully Lispy kernel, be it SMP or not.
In an SMP context, they'd allow fine-grained thread migration.
Also, having FCC means that we factored the two problems
of efficiently synchronizing code and data between the processors,
which is a great win, as it cuts SMP support code (and SMP locks) in two.
Final note: threadish stacks *are* one way, among others,
to implement FCCs, and, as I said:

>> If you fear about the power of duplicating continuations,
You can force a linear context around them,
by tagging them as linear/unique objects,
in which case they are isomorphic to thread states,
only you could manipulate them with the same ease as any reifed object.

> IIRC, it's possible to implement them without efficiency loss.
[Description of a SML/NJish continuation in heap]
Yup. Again, as for SMP, the same multiheap trick as needed
to efficiently use SMP&GC can be used for continuations.
Actually, a simple Lisp implementation over SMP would do
as if it were distributed computing with a really fast network
(plus we'd factor the problems of SMP and Distributed Implementations).
   Of course, getting special heaps/stacks to store continuations
might still be a performance boostup; but because we have factored
continuations, this optimization will appear as a particular instance
of a more general optimization that can benefit all code,
not only continuations.

Enough said. I feel like hbaker
might already have written most/all of this in his papers...


TUNES is a Useful, Not Expedient System