[Stackless] Re: [Python-Dev] Stackless pages

Christian Tismer tismer at tismer.com
Mon Nov 6 20:04:12 CET 2000


Jeremy Hylton wrote:
> 
> >>>>> "CT" == Christian Tismer <tismer at tismer.com> writes:
> 
>   >> I should clarify exactly what I am worried about with C API
>   >> calls.  I don't care if they never return, which is already
>   >> possible since it could invoke some Python code that goes into an
>   >> infinite loop.  I am worried about a C API call that itself never
>   >> returns even though one of its parents does.
> 
>   CT> Shure. It does return, but it might not have done its expected
>   CT> work. Instead it tells you that some work needs to be done.
> 
>   >> I am worried, as Christian explained, about a C API call that
>   >> receives the "unwind token" when it isn't expecting it.
> 
>   CT> This can never happen. All those functions a new functions. All
>   CT> old functions do what they tell to do.
> 
> I'm getting closer, but still not there.  Your first response says it
> will return but it may not have done what was expected.  Your second
> response says this can never happen.  I thought I was asking the same
> question both times :-).

If any function of the current API is called, it will return,
after doing what was desired to do, or return with an exception,
exactly like now.

> If we pick an old function -- PySequence_Tuple -- what happens when it
> recursively invokes the interpreter mainloop at then calls a
> continuation that was bound before the call to PySequence_Tuple?

The continuation will be called, regardless how it was created
and when. The current scheduler will run eval_code2_loop until
the frame is seen which is awaited by the calling interpreter.
If this frame is seen at some time, everything is fine, and
this recursion will be finished normally.

The only problem is when this chain of frames tries to return
to a frame which is still sitting in an earlier interpreter
mainloop which is still sitting on the stack, waiting for
the current recursion to finish.
Such a frame is locked. It is unable to spawn a continuation
frame. Instead, it raises an exception, and your PySequence_Tuple
also returns an exception. This is just fine.

Take another look at it:
With stackful Python, you have interpreter recursions and
Python frames tightly coupled. No switching is possible.
Every interpreter *owns* its current frame. It modifies it.
>From a stackless view, it is impossible to take a snapshot
(continuation frame) of such a frame under modification.

Now, with Stackless Python, you still have interpreter recursions
and frames *owned* by interpreters, just that there are now
more frames between these frames.
In an ideal world, you have only one interpreter, controlling
all the chained frames as they come.
In the less ideal, stackless world, you still have a couple
of frames which cannot create continuation frames, so they
never can become a jump target.
What we have is both: Stackful behavior for some frames,
stackless behavior for the frames in between.

Maximizing the number of stackless frames makes Stackless
better. The rest is nothing else than what we have today.
And all my machinery just ensures that this hybrid design
never breaks.

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 starship.python.net
http://starship.python.net/mailman/listinfo/stackless



More information about the Stackless mailing list