Continuations, concurrency, yada yada...

Lee Salzman lsalzman1 at cox.net
Tue Oct 25 13:50:36 PDT 2005


Here is my train of thought which may explain to some small extent why I 
  am undecided on many of the issues related to concurrency:

It can be fun to think, "Features A, B, and C would be so cool and would 
solve all our problems!" Unfortunately, as the guy who is in charge of 
Slate's architecture, I have a different viewpoint on this. If it can't 
be implemented efficiently, and it is not sufficiently orthogonal to 
other features, it will almost never get used.

Now, when I think of continuations specifically, two thoughts come to 
mind: either horrible inefficiency, or catastrophic overhaul still with 
inefficiency. You're either faced with copying large parts of the stack 
   (you might consider that a vote for delimited continuations, if any) 
or getting rid of the stack entirely in favor of a garbage collector 
nursery. I am not even sure what havoc the catastrophic overhaul option 
would play on a dynamic compiler.

If one wants to use continuations as a poor man's thread, I am more 
partial to coroutines. They better capture this idiom, because to an 
extent, they are just cooperative threads. We already have very 
efficient non-local returns (which we use to great effect in the 
condition system), so continuations for that purpose are not essential.

But if one just wants poor man's threads, then real threads are better.
Real threads need to be implemented at some point, and having a feature 
which is poorly orthogonal to real threads does not bode well for that 
feature.

Now, there are other uses of state resumption in the small that I am 
more sympathetic to such as generators, which coroutines do really well.
But you have to ask, how pervasively is one going to use this? 
Generators are something that could be used extremely pervasively if one 
wanted to. If the tool they are implemented with is so grossly 
inefficient it makes you cringe and the system itself choke on their 
very use, how pervasively will you want to use them still?

So there are two thing we're trying to grasp at here: state resumption 
in the small (I stress: in the small) and larger scale concurrency. Now, 
I still have not found a compelling list of things that can only be 
implemented with small-scale state resumption that would make me run out 
and overhaul things just to support it. I am also unsure of the extent 
to which the small-scale and the larger-scale necessarily conflict. It 
just doesn't feel like the available options have a satisfying level of 
efficiency and orthogonality.

I am still waiting for a spark of inspiration to go one direction or 
another. Maybe someone can manage to convince me.




More information about the Slate mailing list