[Stackless] The Future of Stackless

Andrew Francis andrewfr_ice at yahoo.com
Tue Dec 25 19:32:50 CET 2007


Hello Andrew and Colleagues:

>http://www.artima.com/weblogs/viewpost.jsp?thread=214235

>You should take it that many very smart and
>experienced people have  wanted this, looked into the
>problem, and decided it was too  complicated without
a >major undertaking.


Okay, I read the FAQ and have heard some of these
arguments before. However these approaches strike me
as a "boil the ocean" solution. Perhaps a simpler
solution will please 80% of the users whom wish to
exploit multiple CPUs.

"I want to point out one more time that the language
doesn't require the GIL -- it's only the CPython
virtual machine that has historically been unable to
shed it."

Taken from the "It isn't Easy to Remove the GIL" by
Guido von Russum

AF> In a past course, I encountered Nancy Lynch's
AF> Synchronizer model (presented in the Distributed
AF> Algorithms book) that very much describes
Stackless
AF> Python's scheduler.


AD>The scheduler is the least of the problems. 
Quoting AD>from the FAQ:

...

AD>    And finally, once you have multiple
interpreters AD>not sharing any state, what have you
gained over AD>running each interpreter in a separate
process?

Again, I maybe speaking out of my hat but....

I am running with the assumption that Lynch's model
(or some other formal model) gives good insights into
a distributed solution (I need to review the models).
In the case of Stackless Python, the scheduler is in
essence, a global process synchronizer. I think
understanding how the Stackless scheduler can be
safely distributed amongst multiple CPUs is a step in
the right direction. For instance, I can see coarse
grained solutions where say, where Twisted is running
under one CPU and communicating with Stackeless
through queues.

Again, we don't have assume that we are restricted by
all of the CPython's GIL constraints. Also a decent
solution may entail placing additional restrictions on
the developer.

I guess my point is that it would be desirable to have
some conceptual model that allows us to analyse issues
and steadily improve Stackless Python's power and
performance. 

Cheers,
Andrew


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




More information about the Stackless mailing list