Alternatives to Stackless Python?

[binarybana]

After recently getting excited about the possibilities that stackless
python has to offer
(http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/)
and then discovering that the most recent version of stackless
available on stackless.com was for python 2.2 I am wondering if
Stackless is dead/declining and if so, are there any viable
alternatives that exist today?

I found LGT http://lgt.berlios.de/ but it didn't seem as if the
NanoThreads module had the same capabilites as stackless.

 

[Stephan Diehl]

After recently getting excited about the possibilities that stackless
python has to offer
(http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/)
and then discovering that the most recent version of stackless
available on stackless.com was for python 2.2 I am wondering if
Stackless is dead/declining and if so, are there any viable
alternatives that exist today?

Well, it's not dead and the last recent version is for python 2.3
The developer of stackless, Christian Tismer, is one of the main
developers of the PyPy project. (http://codespeak.net/pypy)
For this reason, there is an extremely good chance that the ideas
behind stackless will survive .
Visit www.stackless.com for further info.

 

[simonwittber]

I found LGT http://lgt.berlios.de/ but it didn't seem as if the

NanoThreads module had the same capabilites as stackless.

What specific capabilities of Stackless are you looking for, that are
missing from NanoThreads?


Sw.

 

[Peter Hansen]

What specific capabilities of Stackless are you looking for, that are
missing from NanoThreads?

While I can't speak for the OP, isn't it the case that the threadlets in
Stackless (sorry, don't know what they are really called) are true
threads in the sense of being able to switch contexts no matter how far
down in a set of nested calls they might be? And that NanoThreads are
simply generators, which means you can switch contexts only at the top
level, with a yield statement?

I don't know what the OP wants, but I could imagine that would be a
pretty fundamental difference (if I'm right about Stackless).

-Peter

 

[D H]

After recently getting excited about the possibilities that stackless
python has to offer
(http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/)
and then discovering that the most recent version of stackless
available on stackless.com was for python 2.2 I am wondering if
Stackless is dead/declining and if so, are there any viable
alternatives that exist today?

I found LGT http://lgt.berlios.de/ but it didn't seem as if the
NanoThreads module had the same capabilites as stackless.

See also greenlets, which work with regular cpython:
http://codespeak.net/py/current/doc/greenlet.html
http://agiletesting.blogspot.com/2005/07/py-lib-gems-greenlets-and-pyxml.html

You'll probably need to get it via an svn client (such as tortoisesvn on
windows): http://codespeak.net/py/current/doc/getting-started.html

 

[Christophe]

(e-mail address removed) a écrit :

What specific capabilities of Stackless are you looking for, that are
missing from NanoThreads?

Capabilities of the different "threadlike" systems are somewhat muddy.
What myself I like in stackless is :
- you can put context switching instuctions anywhere in the callstack
without having to explicitely chain the operation
- pickle support

Not sure if greenlets support pickling yet. There are no info on that
point and my tests weren't succesful.

 

[Olivier Dormond]

(e-mail address removed) a écrit :


Capabilities of the different "threadlike" systems are somewhat muddy.
What myself I like in stackless is :
- you can put context switching instuctions anywhere in the callstack
without having to explicitely chain the operation
- pickle support

Not sure if greenlets support pickling yet. There are no info on that
point and my tests weren't succesful.

The greenlets play with the underlying CPU stack directly so I don't
think they could ever be pickled.

 

[Christophe]

Olivier Dormond a écrit :

The greenlets play with the underlying CPU stack directly so I don't
think they could ever be pickled.

Then they are useless for nearly all the uses cases I need them :/ And
that's why stackless is still relevant here. Or maybe pypy too but it's
still a long time to go.

 

[simonwittber]

While I can't speak for the OP, isn't it the case that the threadlets in
Stackless (sorry, don't know what they are really called) are true
threads in the sense of being able to switch contexts no matter how far
down in a set of nested calls they might be? And that NanoThreads are
simply generators, which means you can switch contexts only at the top
level, with a yield statement?

I don't know what the OP wants, but I could imagine that would be a
pretty fundamental difference (if I'm right about Stackless).

Yes, NanoThreads are very different to Stackless. I was curious to see
what the OP's requirements were, to determine if the requirement could
possibly be implemented using NanoThreads. A NanoThread is not required
to be a generator, it only has to look and work like a generator, which
opens up the possibility of implementing a custom NanoThread using a
normal Python class.

Sw.

 

[binarybana]

Honestly I am not knowledgeable about either option but mainly I was
specifically targetting my feature set towards the things that a higher
level game engine would need such as the one described here:
http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/
Which I guess the main difference that I see between stackless and
NanoThreads is the ability to communicate between threads through
channels and other methods. This is very important in games where the
actors need to communicate among each other to create interactive and
interesting gameplay.

And perhaps scheduling overhead, memory costs and slow thread creation
could be otherh areas where the two differ (but I am unsure). And
finally, how good is NanoThreads at non-preemptive multithreading and
event-driven control? These are more areas that I see the two possibly
differing.

Also, Greenlets look really interesting, I will have to evaluate these
more closely.

 

[Christian Tismer]

While I can't speak for the OP, isn't it the case that the threadlets in
Stackless (sorry, don't know what they are really called) are true
threads in the sense of being able to switch contexts no matter how far
down in a set of nested calls they might be? And that NanoThreads are
simply generators, which means you can switch contexts only at the top
level, with a yield statement?

I don't know what the OP wants, but I could imagine that would be a
pretty fundamental difference (if I'm right about Stackless).

You are.

--
Christian Tismer :^) <mailto:[email protected]>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

 

[Christian Tismer]

Christophe wrote:
....

Not sure if greenlets support pickling yet. There are no info on that
point and my tests weren't succesful.

Greenlets refine a concept of Stackless 2.0 which was orthogonal
to the Python implementation in a sense that they did not
conflict at all. This is less efficient than collaborative
task switching, but allows greenlets to exist without any
maintenance.

A Stackless subset based upon Greenlets is in discussion.

Platform independent Pickling support of running tasklets is
almost impossible without support from the Python implementation.
I see this as an entry point for people to try these ideas.
The switching speed is several times slower by principle.

ciao - chris

--
Christian Tismer :^) <mailto:[email protected]>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/