[Python-Dev] coroutines vs. continuations vs. threads

Christian Tismer tismer at appliedbiometrics.com
Mon May 17 22:03:01 CEST 1999


Aaron Watters wrote:
> 
> The ineffible Gordon McMillan retorts:
> 
> > As a fuddy-duddy old imperative programmer, I'm inclined to think
> > "state machine". But I'd guess that functional-ophiles probably see
> > that as inelegant. (Safe guess - they see _anything_ that isn't
> > functional as inelegant!).
> 
> As a fellow fuddy-duddy I'd agree except that if you write properlylayered
> software you have to unrole and rerole all those layers for every
> transition of the multi-level state machine, and even though with proper
> discipline it can be implemented without becoming hideous, it still adds
> significant overhead compared to "stop right here and come back later"
> which could be implemented using threads/coroutines(?)/continuations.

Coroutines are most elegant here, since (fir a simple example)
they are a symmetric pair of functions which call each other.
There is neither the one-pulls, the other pushes asymmetry, nor
the need to maintain state and be controlled by a supervisor
function.

> I think this is particularly true in Python with the relatively high
> function
> call overhead.  Or maybe I'm out in left field doing cartwheels...
> I guess the question of interest is why are threads insufficient?  I guess
> they have system limitations on the number of threads or other limitations
> that wouldn't be a problem with continuations?  If there aren't a *lot* of
> situations where coroutines are vital, I'd be hesitant to do major
> surgery.

For me (as always) most interesting is the possible speed of
coroutines. They involve no threads overhead, no locking,
no nothing. Python supports it better than expected. If the
stack level of two code objects is the same at a switching point,
the whole switch is nothing more than swapping two frame objects,
and we're done. This might be even cheaper than general call/cc,
like a function call. Sam's prototype works already, with no change to
the
interpreter (but knowledge of Python frames, and a .dll of course).

I think we'll continue a while.

continuously - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home




More information about the Python-Dev mailing list