[Stackless] The Future of Stackless

[Andrew Dalke]

On Dec 24, 2007, at 8:15 PM, Andrew Francis wrote:
> I don't see why a Stackless Python derivative could
> not be created to experiment with alternatives to the
> GIL...

http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global- 
interpreter-lock

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.

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


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

    It would be a tremendous amount of work, because many object

    implementations currently have global state. For example, small

    integers and short strings are cached; these caches would have

    to be moved to the interpreter state. Other object types have

    their own free list; these free lists would have to be moved

    to the interpreter state. And so on.



    And I doubt that it can even be done in finite time, because

    the same problem exists for 3rd party extensions. It is likely

    that 3rd party extensions are being written at a faster rate

    than you can convert them to store all their global state in

    the interpreter state.



    And finally, once you have multiple interpreters not sharing

    any state, what have you gained over running each interpreter

    in a separate process?


These are changes to existing code which was written with the  
assumption that there is a GIL.  To get rid of the GIL means changing  
all of that code.

A Python implementation can be built without a GIL.  Jython and  
IronPython prove that.

> Also I believe Stackless Python's channels resemble channels used  
> the Transputer's
> programming language, Occam.

It's a common idiom also found in other languages.  The Occam  
heritage derives from Hoare's "Communicating Sequence Processes".
   http://en.wikipedia.org/wiki/Communicating_sequential_processes


I'm having to recall vague memories here.  The chip we used had  
only .. 4 channels per processor? ... and no support for  
communications with anything other than the processor on the other  
side of the channel.  The group I was in had some hand-made machine  
based on Transputers and the internal communications architecture was  
a systolic loop: two channels to send/receive to the processor up the  
loop, and two to send/receive down the loop.

The T9000 was supposed to support more complex connections but it was  
very delayed to market and it wasn't cost effective to use.  It might  
not even have made it to market.

In that hardware context, Occam wasn't like Stackless because the  
hardware was only point-to-point.  Ahh, here's a quote from the FAQ at

http://www.wizzy.com/wizzy/transputer_faq.txt

    A channel is a one way communication between (exactly) two  
processes.
    Every channel communication is synchronising. If process A tries to
    send a message (with out) to process B on channel C, it will block
    until B does a receive (with in) on channel C. If the receiver is
    the first to try to communicate, the reverse will happen: the  
receiver
    will block until the sender sends the message.

Stackless supports multiple senders and receivers on a channel.


Interesting.  You can get a portable version of Occam from http:// 
occam-pi.org/


				Andrew
				dalke at dalkescientific.com