[Stackless] The Future of Stackless
andrewfr_ice at yahoo.com
Mon Dec 24 20:15:43 CET 2007
Hello Andrew, Richard and Colleagues:
>Stackless tracks CPython. CPython is not getting rid
>of the GIL so therefore Stackless will always have
>the GIL. Changing CPython to get rid of the GIL is
>extremely hard, for technical and social reasons.
I'll begin by saying I have little experience with
issues pertaining to using multiple processors and
associated low level issues.
I don't see why a Stackless Python derivative could
not be created to experiment with alternatives to the
Some blue sky thinking....
In a past course, I encountered Nancy Lynch's
Synchronizer model (presented in the Distributed
Algorithms book) that very much describes Stackless
Python's scheduler. Also I believe Stackless Python's
channels resemble channels used the Transputer's
programming language, Occam.
In the case of the Lynch Synchronizer, what is
interesting is that for a global synchronizer, one can
create a network of local synchronizers. Perhaps these
models could give insights into an alternative
approach that better manipulates multiple CPUs? As a
starter, keep things simple by just focusing on a
>You could always run multiple Python instances and
>migrate the tasklets between them using pickling.
>is effectively what Linden Labs do (or did?) for
Interesting reference. So far, I have been able to
pickle my WS-BPEL processor and restart it. The gotcha
was ensuring references to Twisted were not pickled.
Very soon, I am going to try pickling WS-BPEL
processes (read groups of related tasklets) and moving
them to another processor on another machine.
Never miss a thing. Make Yahoo your home page.
More information about the Stackless