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

Christian Tismer tismer at tismer.com
Sat Jan 19 23:09:10 CET 2002


[Gordon, I got a problem with you mailer, works through the list only]

Gordon McMillan wrote:

...


>>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").


Yes. We can refine later after the basics work.

> 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.


Yes, this is a limit. Even worse, I will not give you access
to a caller or a caller's caller, you get just the tstate
handle of the curent frame chain. This is always the dog's
tail, whether it shrunk meanwhile or not.
What we are grabbing are "running continuations", the thing
is modified when run, it is always the latest stack entry,
and this will freeze when you switch the chain, until it
is switched back.

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


Ditto.

> [I'm guessing that some kind of "call_with" will be simpler to 

 > implement than "continuation.caller" because it probably means less
 > stack-twiddling.]

I think of the tstate a an array of slots, with one allways
currently active. We can put wrappers around these slots
and use them as call-with parameters. This seems to be
safe and simple. I just don't have a name for these objects,
since they will both serve as uthreads and as coroutines.

> [Sam]
> 
>>>>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 :-).


Sure. I just meant: Why did Tim's example need a specialist?
When I know that the compiler does the right think, I just
disassemble some sample code and imitate. ?

cheerio - 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
http://www.tismer.com/mailman/listinfo/stackless



More information about the Stackless mailing list