Stackless 3.0 alpha 1 at blinding speed

[Tim Peters]

[Courageous]
> ...
> In environments that I work on where continuations aren't available,
> but the same features must exist, the hand-rolled equivalent is a set
> of "parked" threads whereby some scheduler is written to selectively
> activate them. That's how they work, conceptually. A continuations is
> a marker for a "place one can return to whenever one might want". No
> big deal, really. Doesn't have to be complicated.

Except that a collection of threads isn't as powerful as continuations.  As
soon as "the program counter" changes in one of those threads, the
continuation it's standing in for has been changed.  A true continuation can
be invoked any number of times, starting at exactly the same state each
time.  You'd have to augment those threads with some platform-specific
grunge to clone the thread control state top-to-bottom to repair that
weakness.

> 'Course the implementation details may be a bit harder to explain,
> depending. :-)

That's the rub.  Continuations are simple from a very abstract view, in
function spaces.  Implementing them efficiently on real hardware with finite
resources is a challenge.  Alas, people tend to overlook that implementing C
call semantics efficiently on real hardware with finite resources is a
challenge too -- and C was designed to be easy to implement, while
continuations were designed to scratch a theoretical itch.