[Python-Dev] 'stackless' python?

[Christian Tismer]

Guido van Rossum wrote:
> 
> Sam (& others),
> 
> I thought I understood what continuations were, but the examples of
> what you can do with them so far don't clarify the matter at all.
> 
> Perhaps it would help to explain what a continuation actually does
> with the run-time environment, instead of giving examples of how to
> use them and what the result it?
> 
> Here's a start of my own understanding (brief because I'm on a 28.8k
> connection which makes my ordinary typing habits in Emacs very
> painful).
> 
> 1. All program state is somehow contained in a single execution stack.
> This includes globals (which are simply name bindings in the botton
> stack frame).  It also includes a code pointer for each stack frame
> indicating where the function corresponding to that stack frame is
> executing (this is the return address if there is a newer stack frame,
> or the current instruction for the newest frame).

Right. For now, this information is on the C stack for each called
function, although almost completely available in the frame chain.

> 2. A continuation does something equivalent to making a copy of the
> entire execution stack.  This can probably be done lazily.  There are
> probably lots of details.  I also expect that Scheme's semantic model
> is different than Python here -- e.g. does it matter whether deep or
> shallow copies are made?  I.e. are there mutable *objects* in Scheme?
> (I know there are mutable and immutable *name bindings* -- I think.)

To make it lazy, a gatekeeper must be put on top of the two
splitted frames, which catches the event that one of them
returns. It appears to me that this it the same callcc.new()
object which catches this, splitting frames when hit by a return.

> 3. Calling a continuation probably makes the saved copy of the
> execution stack the current execution state; I presume there's also a
> way to pass an extra argument.
> 
> 4. Coroutines (which I *do* understand) are probably done by swapping
> between two (or more) continuations.

Right, which is just two or three assignments.

> 5. Other control constructs can be done by various manipulations of
> continuations.  I presume that in many situations the saved
> continuation becomes the main control locus permanently, and the
> (previously) current stack is simply garbage-collected.  Of course the
> lazy copy makes this efficient.

Yes, great. It looks like that switching continuations
is not more expensive than a single Python function call.

> Continuations involving only Python stack frames might be supported,
> if we can agree on the the sharing / copying semantics.  This is where
> I don't know enough see questions at #2 above).

This would mean to avoid creating incompatible continuations.
A continutation may not switch to a frame chain which was created
by a different VM incarnation since this would later on
corrupt the machine stack. One way to assure that would be
a thread-safe function in sys, similar to sys.exc_info()
which gives an id for the current interpreter. continuations
living somewhere in globals would be marked by the interpreter
which created them, and reject to be thrown if they don't match.

The necessary interpreter support appears to be small:

Extend the PyFrame structure by two fields:
  - interpreter ID  (addr of some local variable would do)
  - stack pointer at current instruction.

Change the CALL_FUNCTION opcode to avoid calling eval recursively
in the case of a Python function/method, but the current frame,
build the new one and start over.
RETURN will pop a frame and reload its local variables instead
of returning, as long as there is a frame to pop.

I'm unclear how exceptions should be handled. Are they currently
propagated up across different C calls other than ceval2
recursions?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home