Stackless python and microthreads

[Matt Leslie]

Hi,

I'm trying to use microthreads under stackless python, since they sound
like exactly what I am after, but I am having very little success.
I've got a fresh install of python 2.3.3 from python.org, then
downloaded the binary python2.3 release of stackless python from
www.stackless.com. This contained three files:

python23.dll, python23.lib, python23.exp

I searched for the original versions of these files, and copied:

stackless python23.dll over c:\winnt\system 32\python23.dll
stackless python23.lib over C:\Program Files\python2.3 \libs\python23. lib

Since I believe .exp files are associated with .lib files. I put the
..exp file in the same place as the lib. There was no existing file with
this name on my file system.

I then downloaded the microthreads package from
http://willware.net:8080/uthread.py

I then ran python, type 'import uthread' and immediately got the
following error.

---------------------------------------
Python 2.3.3 Stackless 3.0 040407 (#51, Apr 7 2004, 19:28:46) [MSC
v.1200 32 bit (Intel)] on win32
Type "help", "copyright" , "credits" or "license" for more information.

import uthread.py

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "uthread.py ", line 35, in ?
import continuation, sys, traceback, bisect, time, StringIO
ImportError: No module named continuation

Has anyone run into this before? Can someone tell me where to find this
continuation module?

Thanks,
Matt

[Mike C. Fletcher]

Continuations (which are the coolest things since programming was
invented) were forced out of Stackless Python around the end of version
2.0 for political reasons IIRC. Current Stackless doesn't have
continuation support at all, so any version of micro-threads written to
use continuations is just dead-on-arrival for the current version.
Stackless 1.0 and 2.0 were only for pre-2.3 releases of Python AFAIK.

I would imagine that *someone* has written a Tasklets-based
micro-threading implementation for the new Stackless (after all,
micro-threading is AFAIK *the* major use-case for Stackless (save for
those of us who like to play around with new modes of programming)) and
you'll just need to poke around for that rewrite.

In a former life I got paid to work on extending the continuation-based
micro-thread implementation. .. continuations are the most awesome toys
you can imagine... we will all mourn their passing in time...

Good luck,
Mike

Matt Leslie wrote:
....

I'm trying to use microthreads under stackless python, since they
sound like exactly what I am after,
....
python23.dll, python23.lib, python23.exp
....
I then downloaded the microthreads package from
http://willware.net:8080/uthread.py
....
ImportError: No module named continuation

....
_______________ _______________ _______________ ___
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

[Peter Hansen]

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? ;-)

-Peter

[Donn Cave]

Quoth Peter Hansen <pe***@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, do**@drizzle.co m

[Michele Simionato]

"Mike C. Fletcher" <mc******@roger s.com> wrote in message news:<ma******* *************** *************** *@python.org>.. .

Continuations (which are the coolest things since programming was
invented) were forced out of Stackless Python around the end of version
2.0 for political reasons IIRC. Current Stackless doesn't have
continuation support at all, so any version of micro-threads written to
use continuations is just dead-on-arrival for the current version.
Stackless 1.0 and 2.0 were only for pre-2.3 releases of Python AFAIK.

In a former life I got paid to work on extending the continuation-based
micro-thread implementation. .. continuations are the most awesome toys
you can imagine... we will all mourn their passing in time...

Good luck,
Mike

Uhm ...

My experience with continuations (in Scheme) is limited, but I really
wonder if continuations have a place in a high level programming language.
I mean, continuations are basic building blocks: you can build on top
of them exception systems, generators, coroutines, microthreads, etc,
and it is an interesting learning experience to understand how this is
done.

However, to pass from continuations to something useful takes a
LONG way. Continuations are a too low level concept. A high level language
should already provide the right high level tools. I mean, the language
designer should implement generators, exception systems, microthreads, etc.
not the application programmer. When you have the high level concepts written
down by others, you don't need continuations.

So I guess now Stackless has microthreads built inside, and the application
programmer is not forced to write them on top of continations.

Speaking in general, generators and the current exception system are more
than enough for my typical needs in Python: which kind of applications do
you have in mind where you would like to have continuations? (a part from
microthreads and things like changing the language introducing new
control structures, etc, all stuff than should not be left to the
application programmer, IMHO).

Michele

[Michael Walter]

> My experience with continuations (in Scheme) is limited, but I really

wonder if continuations have a place in a high level programming language.
I mean, continuations are basic building blocks: you can build on top
of them exception systems, generators, coroutines, microthreads, etc,
and it is an interesting learning experience to understand how this is
done. Yeah exactly, they are one reason which allows Scheme to be really
high-level.

They're pretty useful for web applications, too -- the difference to
above-mentioned examples would be that IMHO there is no adequate
alternative to them in current Python.
However, to pass from continuations to something useful takes a
LONG way. Continuations are a too low level concept. That probably depends on the point of view. I don't think it matters
much whether a specific feature is built-in into the language as such or
part of the/a standard library.
A high level language should already provide the right high level tools. I mean, the language designer should implement generators, exception systems, microthreads, etc. not the application programmer. When you have the high level concepts written
down by others, you don't need continuations. Would you have an idea on how a higher-level replacement for
continuations in web application development? I'm excited (and _not_
being any sarcastic or stuff, honestely!).
Speaking in general, generators and the current exception system are more
than enough for my typical needs in Python: which kind of applications do
you have in mind where you would like to have continuations? (a part from
microthreads and things like changing the language introducing new
control structures, etc, all stuff than should not be left to the
application programmer, IMHO).

Web application development involving Continuations (such as in Seaside,
the PST web server etc.).

Cheers,
Michael

[Just]

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

not the application programmer. When you have the high level concepts
written
down by others, you don't need continuations.

Would you have an idea on how a higher-level replacement for
continuations in web application development? I'm excited (and _not_
being any sarcastic or stuff, honestely!).

Co-routines.

Just

[Michael Walter]

Just wrote:

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

not the application programmer. When you have the high level concepts
written
down by others, you don't need continuations.

Would you have an idea on how a higher-level replacement for
continuatio ns in web application development? I'm excited (and _not_
being any sarcastic or stuff, honestely!).

Co-routines.

Would you care to elaborate? Can you store the state of a coroutine and
resume it multiple times?

Cheers,
Michael

[Just]

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

Just wrote:

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

Would you have an idea on how a higher-level replacement for
continuatio ns in web application development? I'm excited (and _not_
being any sarcastic or stuff, honestely!).

Co-routines.

Would you care to elaborate? Can you store the state of a coroutine and
resume it multiple times?

You can resume a co-routine multiple times just like you can resume
generators mutliple times, but that's something completely different
from restarting a continuation multiple times.

When you mentioned continuations for web programming, I assumed you
meant their ability to turn flow control inside out (allowing to write
event-based networking code in a more natural way). Co-routines are a
much nicer abstraction for that than continuations.

Just

[Michael Walter]

Just wrote:

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

Just wrote:

In article <2g************ @uni-berlin.de>,
Michael Walter <cm@leetspeak.o rg> wrote:

Would you have an idea on how a higher-level replacement for
continuatio ns in web application development? I'm excited (and _not_
being any sarcastic or stuff, honestely!).

Co-routines.
Would you care to elaborate? Can you store the state of a coroutine and
resume it multiple times?

You can resume a co-routine multiple times just like you can resume
generators mutliple times, but that's something completely different
from restarting a continuation multiple times.

Well, I think you would want to resume it multiple times based on a
given state (essentially like resuming a stored continuation).
When you mentioned continuations for web programming, I assumed you
meant their ability to turn flow control inside out (allowing to write
event-based networking code in a more natural way). Co-routines are a
much nicer abstraction for that than continuations.

Would you have some links/papers for me in regard to web programming and
coroutines? Some quick googling didn't bring anything up (but maybe I'm
just too tired).

What I meant was using continuations for "linear" code flow, such as
mentioned in
http://www.ai.mit.edu/~gregs/ll1-dis.../msg02456.html,
described in http://www.double.co.nz/scheme/modal-web-server.html and
applied in Seaside, Borges, PLT Web Server etc.

Cheers,
Michael