[Stackless] The Future of Stackless

[Andrew Francis]

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
GIL...

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
cooperative scheduler.

>You could always run multiple Python instances and
>migrate the tasklets between them using pickling.

>is effectively what Linden Labs do (or did?) for
>Second Life[1].

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.

Cheers,
Andrew


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs