Continuations and threads (was Re: Iterators & generators)

[Samuel A. Falvo II]

In article <evkhGX$e$GA.79 at cpmsnbbsa03>, Tim Peters wrote:
>The latter are more powerful, but that's not really the attraction.
>Continuations are both fast and space-efficient compared to threads on most
>platforms.  Read Christian's paper!  You'll find, e.g., that his simple
>implementation of generators using continuations ran 3x faster than a simple
>implementation using threads (& on a platform that does a relatively good

This is because the operating system  switches threads, not the application.
At worst case, it does so on an every so often (time-slicing).  At best
case, it will put a thread to sleep as soon as the OS sees that it can't
possibly proceed any further without a message or event from another thread.

Continuations, however, are entirely user-space constructs.  There's no
user-to-kernel-to-user transitions involved.  So of course they're going to
be faster when run under such a system.

Now, implement an operating environment that uses continuations natively,
and you'll find it'll be no faster than using threads.  Why?  Because the
continuation functions are stuff away in kernel-space (otherwise, they
wouldn't be "native" to the operating system).

>coroutine implementation flies (and see Sam Rushing's writings on Medusa &
>friends for deadly practical high-end applications).

I have read up on the Medusa package -- it uses the same technique that
allows the AmigaOS to wipe the floor with almost any other OS even after so
many years -- the LACK of multithreading, and the introduction of
intelligent event notification systems.

>I've never seen an implementation of (pseudo)threads using continuations
>that I thought was suitable for more than toy researchy problems or
>educational purposes.  When it comes to "real work", the pragmatics are

Because continuations are inherently language specific.  If languages like C
and its ilk used indirect stack frames (instead of embedded stack frames),
continuations in C would be more than possible, and threading would be far
easier.  Billy and I had a discussion on this topic the other day, in fact.

>code won't let Python "timeslice" it).  So Python threads serve important
>purposes Python continuations couldn't touch, and also for which the latter
>aren't pragmatically suited.

Why can't Python's threads package use OS-native threading API, assuming one
exists?

>space, while a continuation will usually suck up only a few hundred bytes.

What is your basis for this conclusion?  An execution context is an
execution context is an execution context -- the amount of information which
is required to be stored is going to be roughly equal no matter what.  In
fact, continuations will consume more space than a pure thread specifically
because a function's "frame" isn't stored on "the stack."  Thus, something
somewhere must maintain a reference to it.  Then consider that there can be
several "continuation objects," where each object stores a branch of the
frame tree within it.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA