Stackless python and microthreads

[Donn Cave]

Quoth Peter Hansen <peter at engcorp.com>:
| Mike C. Fletcher wrote:
|
| > continuations are the most awesome toys 
| > you can imagine... we will all mourn their passing in time...
|
| Will that be _before_, or _after_ we understand what they are?  ;-)

I gave them a try, and I mourn them with a touch of relief, I guess.
I'm the guy who won't bother to learn list comprehensions and generally
despises cool gimmicks, but continuations were more than just cool,
they were terribly powerful.

I hooked them into a graphics toolkit wrapper with an event dispatching
model where each window, network connection etc., ran in its own native
thread.  No blocking, always ready to respond to a new message.  When a
couple of these threads have to interact, they would queue messages back
and forth, and the programming paradigm can get awkward - a lot of state
can pile up as everyone's trying to keep track of their progress through
some kind of procedure.

Well, suppose you send your message and save the whole function state
somewhere, and return to the dispatcher.  When the response comes back,
you pick up the function state and continue it, feeding the response in.

Now instead of a tedious kind of state machine, you're writing an plain,
ordinary function that sends messages to its peer and looks at the response,
as though that were all synchronous, and it's so much simpler.  Yet the
execution underneath that isn't synchronous at all, because your computation
is suspended in between your send and the response.  It really does return
every time it sends a message, it just starts up next time where it left
off.

Of course it's hairy, too.  That's where the relief comes in.  I'll never
be able to use continuations ... but then, I'll never have to deal with
anyone else's code that uses them.

	Donn Cave, donn at drizzle.com