Home Original page

Continuations and threads (was Re: Iterators & generators)

Tim Peters tim_one at email.msn.com
Fri Feb 18 01:55:15 EST 2000 
[Aahz Maruch]
> ...
> No, no, I meant that one could implement continuations using fork()
> and IPC.  It should therefore be possible to implement continuations
> using threads.  And I think that's all the Timbot meant.

It wasn't, but maybe I should pretend it was <wink>.  Tried to clarify this
in another msg.

The difficulty with using fork() is that continuations are entirely about
capturing control-flow state and nothing about capturing data state (except
for such "implementation data" that's stacked to record info about control
flow).  A resumed continuation "sees" changes in ordinary data state made
since the time it was captured.  If a continuation *didn't* see changes in
data state, then invoking it later multiple times would do exactly the same
thing each of those times (barring connection to an external source of
non-determinacy, etc).  And that's pretty useless.

Suggestion:  forget all this.  It's at the wrong level for almost everyone
struggling to follow it.  While continuations were a kind of breakthrough in
the theoretical world, in practice they're simply an *implementation
technique*.  Almost nobody is ever going to want to use them directly.

What's *interesting* is what the language could provide if they were
available to a few insane souls to build on "under the covers".  A Scheme
True Believer builds all control flow (from function calls thru exceptions
to pseudo-threading) on top of them.  Python won't do that, and I expect
Guido is just irked at suggestions that "he should" (why the hell should he
<wink>?).

In Python the value would be for what they could provide we don't already
have:  not exception-handling, but (most clearly) lightweight generators &
coroutines, and (less clearly) lightweight alternatives to threads.  The
pragmatics of Stackless are such that you can have thousands of
"pseudothreads" running even on feeble platforms with no thread support; and
without the C stack interwined in the program state, it's even possible we
could whip something up to, e.g., freeze a (pure) Python program in
mid-stream, pickle it, send it across the web, and resume it where it left
off on some other architecture.

Indulge some crazy-ass fanatasies!  Worrying about the mechanics of
continuations here is akin to a debate starting about what kind of numeric
types P3K should offer, that degenerates into an endless discussion about
how best to build adder circuits in .18 micron technology <0.9 wink>.

they're-a-means-not-an-end-ly y'rs  - tim
More information about the Python-list mailing list