[pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless

Christian Tismer tismer at stackless.com
Sat Oct 22 00:47:36 CEST 2005


Armin Rigo wrote:

> Hi all,
> 
> Re "continuation": I'm sorry for all the confusion.  I should have
> called these objects what they really are in C, i.e. 'frame_stack_top'
> objects.  Not more, not less.

I strongly do agree!

Maybe just "suspended_frame" or "suspended_frame_chain" or something?
Maybe "frame_stack_top" is exactly the right wording, see below.


A few thoughts, not well reflected, yet.

The special thing that makes a difference is just the fact that
a suspended_frame does *not* play the role of the current
running stack, but another one that is not executing now.
There can always be only one active frame stack for one real
stack, all others are currently suspended.

But that's not the full story.
Why can something like a suspended frame thing exist at all?

One possible POV is this:
In the case when we are unwinding stacks, we are actually
creating a chain of suspended frames. In that set, every
element of this chain represents a suspended frame in itself.
We have provided a way to stick them together, and we promised
to re-activate them in the necessary order. So it is actually
allowed to consider every element as a suspended frame, together
with its successors.
When we are in the state of all frames being suspended, we are
at the toplevel dispatcher, and we might consider to call any
of the suspended frames, if the overall dependencies stay intact.
By default, this means to restart all frames in the expected order.

Still not the full story. Have a look at ancient Stackless Python:
Here, all frames were CPython frames, chained together via f_back.
This is always a valid chain, regardless how you stick that together.

In our case, this property is not valid, because there is another
promise to fulfil: The chain of frames has to provide the data
type which is expected by the caller. Essentially, we cannot stick
these together in a different order, unless the points where we
might change this sequence has a compatible interface.

Things that we need to obey (repeating Armin, almost completely:

- all suspended frames need to be called at some time, or we leak.

- every suspended frame needs to be called exactly once, or we crash.

These two combine to:

- every suspended frame must be called exactly once.

If PyPy stays as it is at the moment, these rules would maybe enough.
We would be able to change order of execution at every point with
compatible interface.

But there is also the issue of liveness. ATM, refcounting is not using
lifeness considerations of callers. This will most probably happen,
soon, so obeying the explicit calling interface just by type
will not be enough. Instead, we will have to include object identity
into the interface as well:
A suspended frame can only be replaced by an object-identity compatible
frame. In all cases where the calling frame is the creator of an
object passed as a parameter, there is no way to replace the callee
frame, if references are optimized.

This leads me to this conclusion:
Switchable, object-identity compatible frames do not share any
own objects at all with their callees. They can only pass
borrowed objects.

Every suspended frame chain may be broken and re-organized
at points which are object-identity compatible.
Of course, this is achieved the easiest if there are no shared
objects at all. :-)

Armin proposed an interface that
- does not use such references at all
- always uses a specific interface that is built just to support this.

If my considerations are not wrong then this interface is sufficient
but not necessary. This does not mean we should not use it. I just
wanted to point out that switching threadlets can be made slightly
less restrictive, but I have no idea if that is useful at all.

This draft was meant to be a step towards understanding what we
are doing here. Please feel free to extend and correct, and please
ask if I expressed things not clearly enough.

ciao - chris

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



More information about the Pypy-dev mailing list