[Stackless] Ann: Stackless Python is DEAD! Long live Stackless Python

Gordon McMillan gmcm at hypernet.com
Sat Jan 19 19:46:37 CET 2002

Christian Tismer wrote:

> Gordon McMillan wrote:


> > ... My 
> > simple-minded picture is that positions 0..K of the
> > stack (the part before we did anything weird) stay
> > the same. But Christian swaps in / out K+1..top (varying 
> > size) as needed.
> Which direction is your brain's stack? Mine is upside
> down, due to too much debugging. I think we mean the
> same. 

Right. One of us is upside down, but it amounts to the same thing.

[snip nice pictures]

> This was the simple case which is easy to understand.
> A little more complicated is switching between
> uthreads/coroutines. The area which I labelled with
> "top" doesn't need to be always identical. There are
> situations, like the imports at python startup time,
> where the topmost interpreter gets a different stack
> location than the one which drives the interactive
> console, for instance.
> I'm not totally clear yet what exactly needs to be
> saved/restored for a switch.
> Maybe it would be easiest for me if I only allow
> switches if the stacktop is the same?
> I could use some hints from you, please think :-)

I think that's safe (what you call "top" is really "start").

Looking at how I used old Stackless, it seems I really only used continuation.caller(). Translating to the new stackless, that seems to mean "that chunk of 
the stack between the frame that called me and his (relative) 'start'". Any attempt to back up beyond his (relative) 'start' puts me (I think) outside the land of 
coroutines and into the forbidden lands of continuations.

Not quite so sure about uthreads, but my feeling is that's still an acceptable limitation.

[I'm guessing that some kind of "call_with" will be simpler to implement than "continuation.caller" because it probably means less stack-twiddling.]

> >>Seems like this could run into trouble with an optimizing
> >>compiler...
> >>
> > 
> > There may well be a conflict, but it's confined to one C 
> > call, (and one that probably defies most optimizations 
> > anyway). As Tim pointed out in an off-list email, there's
> > deep magic required on platforms that have specialized
> > HW stacks (he used ICON on SPARK as an example).
> Yes, but I don't intend to switch to a different stack,
> I just modify some entries and the stack pointer, nothing
> else than the C compiler does. How can this be so complicated?

Well, not all of us write C compilers in our spare time :-).

-- Gordon

Stackless mailing list
Stackless at www.tismer.com

More information about the Stackless mailing list