[Stackless] Fwd: Questions related to stackless

Christian Tismer tismer at stackless.com
Wed Oct 27 18:48:12 CEST 2004


Jiwon Seo wrote:

> Hello!
> 
> I have questions regarding stackless python, and I guess this mailing
> list is probably right place to ask. :)

Good guess. :)

> All of my question is related to
> http://www.stackless.com/spcpaper.htm#_Toc470444074  <- this paper.
> (I understand that stackless has been changed alot since that paper,
> but I need to understand that paper, since I am supposed to give
> presentation about that - continuation, microthread, etc.)
> 
> questions are
> 
> 1. From that paper, "Figure 1: Multiple Return"case is solved by
> "Figure 2: Frame Mutation". But does it solve following case?
> 
> def foo():
>    a = 10
>    make_and_run_continuation(bar) # --- a)
>    a = 11
>    make_and_run_continuation(zoo) # --- b)
>    a = 12
> 
> In this case, a) and b) return to the same frame, but the state of the
> frame is different. So, I think there should be two original frame,
> not one like Figure 1 says. Am I right?

Not right.
Please drop the frame idea for a moment and think of
continuations. The two continuations consist of two
different program locations. Continuations do not include
local variables.

Now back to frames:
If we are returning multiple times, we have to restore
the program location where we left the frame. This is,
I provide a location and a copy of values on the
expression stack, to be restored. That's all.
The state of local variables is not in the scope of
continuations, that must be handled explicitly.

> 2. Figure 3: Nodes Collect References <-- I don't really understand
> what this diagram says. Could someone please explain this to me? (What
> does this diagram solve, and how, etc) :)

You need to understand figure 2 which explains push-back frames.
This is just a trick to make it possible that a "real" frame
re-enters a former state. I do this with "continuation"
frames, with the only purpose to restore the state
of the real frame and continue there.
This is purely an implementation detail: using extra frames to
make frames behave like continuations, without the overhead
to always work with extra overhead. In a sense, the extra frames
are created when it is necessary. That is when the refcount
is > 1, and the possibility of more than one return exists.

Figure 3 explains how this is technically achieved with
efficiency.
Because frames are referenced by other objects, I cannot
create new frames to replace them when continuations are
needed. Instead, what I do is this:
The currently running "real" frame creates a new frame in
its f_back pointer, while the former "real" frame becomes
the continuation frame. Execution continues with the
newly created one, leaving the continuation as a restartable
entry point.
But this scheme might create long chains of linked
continuation frames under circumstances, which might be
significantly different from O(1) behavior.
Therefore, we carry a PyCoNode object around and adjust all
continuation frames to link to it, and we can reach the
current real frame from any continuation frame in
constant time.

Conclusion: This all has nothing to do with continuation
concepts, it is just an efficient implementation.
For continuations in general, please refer to the
literature.

sincerely -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Carmerstr. 2                 :    *Starship* http://starship.python.net/
10623 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 31 86 04 18  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless



More information about the Stackless mailing list