[Stackless] Pending port of Stackless to Python 2.5b1

Richard richard at ccpgames.com
Wed Jun 28 16:16:30 CEST 2006


I was planning to port Stackless to 2.5 when the final release was
made, if no-one else had done it already.  But I vaguely recall
Christian mentioning to me that it would be worth doing from the
betas and because I wanted a break from my current project, I
took a few hours of my working day yesteday and started the

I budgeted half a working day today to finish the job today
but have been unable to complete the task, having now spent a
whole additional working day on it.  However, it is at the point
where it can be compiled and the interpreter started.  But many
issues remain to be dealt with, as running either the Stackless
unittests or the Python regression tests will show.  And I cannot
justify spending any more time on it until late next week, since
I have a project at work which I need to get out of the way.

If anyone wants to help out, getting the source code from
SVN and running either sets of tests should give you a starting
point.  If no-one feels like they can, or that they have the time,
this is fine too! :)  I should eventually get it done, as time

There are a lot of changes to Python which affect the ways
Stackless does what it does.  The main ones which I had to address,
in order to get the code to compile and run (over and above the
standard porting changes required) were:

1) PyEval_EvalFrameEx

There was a recent change (from 2.3 to 2.4?) where retval was removed
from the PyEval_EvalFrame arguments, which was relatively easily

However in 2.5 PyEval_EvalFrame has been superceded by PyEval_EvalFrameEx
which takes an extra argument.  I didn't really check what this new
argument does, I just changed a lot of Stackless code and functions to
also have this argument.  But.. a lot of these functions and code do not
use this argument (throwflag/exc) and whether they get passed it and
should do something with it, or whether they are not getting passed the
right version of it or.. whatever.. I do not know and have not checked
yet.  This needs to be verified.

2) abstract.c: PyObject_Call

This now explicitly increases the thread state recursion depth before
calling the given python function and decreases it afterwards.  The
problem with this, with regard to Stackless, is that when the main
tasklet is run and then destroyed, the tasklet destruction code
asserts that this recursion depth should be 0.  I haven't thought
this through much, I just undefined the recursion depth changes
in this function for Stackless.

3) Generators

Stackless replaces the generator code with its own.  But now there are
new methods on generators, which allow you to send, close and maybe
some other stuff.  I have not touched these new methods and left them
in place as is.  This is something to look at when the rest of the
port is polished.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list