[Python-Dev] Trial balloon: microthreads library in stdlib (original) (raw)

Talin talin at acm.org
Mon Feb 12 19:25:31 CET 2007

Richard Tew wrote:

See "A Bit Of History" http://svn.python.org/view/stackless/trunk/Stackless/readme.txt

I admit that I haven't given Stackless more than a cursory look over, but it seems to me that the real source of its complexity is because its trying to add a fundamental architectural feature to Python without completely re-writing it.

Writing a purely stateless, "stack-less" language interpreter is not that hard, as long as you are willing to drink the KoolAid from the very start - in other words, you don't allow any function call interfaces which are not continuable. This does make writing C extension functions a little bit harder than before, as you now have to explicitly manage all of your local variables instead of just pushing them on the hardware stack.

(Actually, for "simple" C subroutines that don't call any other interpreted functions, you can write it like a normal C functions just as you always have.)

The nightmare comes when you try to glue all this onto an existing language interpreter, which wasn't written from the start with these principles in mind - AND which doesn't want to suffer the impact of a large number of global changes. To be honest, I can't even imagine how you would do such a thing, and the fact that Stackless has done it is quite impressive to me.

Now, I'm very interested in Stackless, but, as you say, like many people I've tended to shy away from using a fork.

Now, the question I would like to ask the Stackless people is: Rather than thinking about wholesale integration of Stackless into Python mainline, what would make it easier to maintain the Stackless fork? In other words, what would you change about the current Python (it could be a global change) that would make your lives easier?

What I'd like to see is for the Stackless people to come up with a list of design principles which they would like to see the implementation of Python conform to. Things like "All C functions should conform to such and such calling convention".

What I am getting at is that rather that doing heroic efforts to add stackless-ness to the current Python code base without changing it, instead define a migration path which allows Python to eventually acquire the characteristics of a stackless implementation. The idea is to gradually shrink the actual Stackless patches to the point where they become small enough that a direct patch becomes uncontroversial.

-- Talin

More information about the Python-Dev mailing list