[Stackless] Paper question

Christian Tismer tismer at tismer.com
Mon Jan 8 20:55:58 CET 2001


"Krishnaswami, Neel" wrote:
> 
> Hello all,
> 
> On the C-- (http://www.cminusminus.org) mailing list, I saw
> a reference to a paper that may be of interest to the members
> of this list: "Featherweight concurenncy in a portable assembly
> language."

Yes, that's quite interesting. I got a copy before they published
it and had some chance to comment.

> The core neat idea in this paper is the design of a limited version
> of call/cc that allows the efficient implementation of coroutines,
> microthreads, backtracking, and exceptions with restarts while stil
> permitting activation records to be stack-allocated.

Right. What they call continuations are not really continuations,
at most they can be called "one-shot continuations".

> The basic idea is that activation records are stack allocated, and
> a captured continuation is just a pointer into the control stack.
> You can resume a continuation as many times as you like, but if
> the continuation's calling function f returns or if you resume a
> continuation captured by any of f's callers. (These two restrictions
> preserve the stack discipline of the call stack.)

Not true, you cannot resume it more than once. They are one-shot,
since they mutate after they are called, and therefore are a
different continuation.
I could achieve the same effect by simply not trying to catch
a frame, assuming that a frame is never run twice. Their stack
layout assures that automatially.
The paper is more concerned with stack techniques for compilers.
Unless Python adopts such a scheme, it is not so relevant for us.

> Since these applications are AFAICT a pretty close to complete set
> of uses for Stackless, and it still permits great speed, I'm passing
> along a pointer to the paper:
> 
> http://research.microsoft.com/~simonpj/papers/c--concurrency.ps.gz

Ok. It is very clear for me how to implement coroutines and
generators efficiently. The problem is whether we want to support
first class continuations in the future or not. They are much more
powerful, but maybe exactly this power is not needed.
For the time being, I will let them stay in, and rewrite coroutines
and uthreads in plain C, not relying directly on continuations.
There are still some situations where they come in handy.
Maybe they will stay in a seperate module, or they might
fade out completely, I don't know.

But-after-IPC9's-developers-day-we-will-know - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless



More information about the Stackless mailing list