[Stackless] The Future of Stackless
dalke at dalkescientific.com
Tue Dec 25 01:00:30 CET 2007
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
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".
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
A channel is a one way communication between (exactly) two
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
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://
dalke at dalkescientific.com
More information about the Stackless