[Stackless] Ann: Stackless Python is DEAD! Long live Stackless Python
tismer at tismer.com
Sat Jan 19 00:53:21 CET 2002
Jeremy Hylton wrote:
>>>>>>"CT" == Christian Tismer <tismer at tismer.com> writes:
> CT> - Stackless breaks its major axiom now. It is no longer
> CT> platform independent, since it *does* modify the C stack. I
> CT> will support all Intel platforms by myself. For other
> CT> platforms, I'm asking for volunteers.
> What is it that you do to the C stack that makes this possible? Is
> this a standard approach to implementing continuations for which you
> can point us at some papers?
It is not targetted at continuations at all. Ok, what I'm
tweaking is peaces of the stack, that can be seen as
continuations. But I have no plans to make them first class
> How OS-specific are the changes? Is it easy to support Linux, Windows
> 98, and Windows 2000 with the same code base?
It depends on compiler and platform.
What I do should be possible on any compiler/platform,
since it is not so different from the code that the C
In the old layout, I made huge pirouettes in order to
get running C code off the C stack. You remember my
paper. This was very hairy, and it could not give
us complete stacklessness, due to some complicated
calling patterns in object.c and abstract.c . This
turned out to be a dead end.
What I now do is to enforce stacklessness.
The key function is PyEval_EvalCodeEx.
This function calls
retval = eval_frame(f);
and this is exactly what I capture.
This call to eval_frame is wrapped by a special function
of mine, which does the forbidden things.
It checks, whether a recursive call of PyEval_EvalCodeEx
is running. If so, the stack area between the current
PyEval_EvalCodeEx and the former is saved into extra memory.
Then, the current invocation's locals are moved up,
and execution continues there.
That means, there is only one PyEval_EvalCodeEx on the
stack, and we are stackless.
When eval_frame is done, my special routine restores
the former stack state and lets PyEval_EvalCodeEx return,
as if nothing special happened.
The comp/platf specific stuff is just that stack fiddling.
But, since your C compiler all the time emits code for
changing the stack, it must be possible to do that on any
Note that there is now an extra chain of saved stack
slices to be maintained. One could have put them into
the frames, but there are some good reasons not to touch
them, and I also have become a little framo-phobic.
These details can be discussed later.
So far for the stackless matters.
What about coroutines and uthreads?
I have no design of the interface yet, but the internals
The tstate always holds one active uthread/coroutine, which
is exactly one chain of frames, null-terminated, as it
is in Standard Python. Additionally, there is this stack slice
chain. So the only difference is now, that I stop the C stack
from growing and instead have this extra chain.
For uthreads and coroutines, I now allow to create a new
chain of frames. This is similar to real threads.
There will be a single switch() or transfer() function, which
puts the current running chain into a waiting chain list,
and restores one of the waiting frame chains as the current one.
So, the tstate still always has exactly one running chain.
The implementation of this switching thing uses the same
stack fiddling machinery as the stackless implementation
which I sketched above.
I need to think more about the layout of these structures.
At the moment, I'm trying to get the stackless part to run.
This stuff is about two powers of ten easier
than olde Stackless!
what a relief - ciao - chris
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net/
14163 Berlin : PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com/
Stackless mailing list
Stackless at www.tismer.com
More information about the Stackless