Python 2.0 and Stackless

[Christian Tismer]

Vladimir Marangozov wrote:
> 
> Hey, Just, let's talk facts!

Yes, this applies to all of us. :-)

> Just van Rossum wrote:
> >
> > [Jeremy]
> > > It is a conservative response.
> >
> > Jeremy, have you ever *looked* at stackless? ...
> 
> Can't speak for Jeremy, but I did. In detail.

Then please do it again. I think you lost something.

...
> [Just, about compatibility]
> > The stackless API is 100% b/w compatible.
> 
> A fact, as long as we discuss the current API.

I think the current API is the only issue, since it
is about compatibility with the current implementation.
This is fully compatible. The extended API exists too,
but it is no problem to discussand change it. Anyway,
this is not relevant for the decision whether to adopt
it.

> [Just again]
> > There are (or could/should be) additional calls for extension writers
> > and embedders that would like to take advantage of stackless features,
> > but full compatibility is *there*.
> 
> An illusion <wink>.
> 
> Fact is that the stack prevents you from having continuations at the C
> level. But it is also a fact that by removing the stack you lose its
> benefits. So full (functional) compatibility is *not* there.

Here I lost you completely. Which stack are you talking
about? Sur, the C stack is gone in most cases, but instead
we always have the stack which is built from the frame chain.

> Whenever you switch from a pile of execution frames (a stack) to a graph
> of frames, you lose the strict frame ordering typical for a stack.

At any time, the frame chain is a stack. The fact that you
can switch to other chains does not change this.

> One consequence is that given an execution point P, for which there's a
> corresponding frame Pf, with the advent of the stack you can figure out
> the current call path of the program. Without the stack, this is hard!

But you have it, and it is simple.

> This has direct consequences for people interested in serializing the
> interpreter state. Currently, if I stop the interpreter at P, I *can*
> serialize the whole interpreter state (including the objects and the
> stack of execution frames), then restore it, say on another machine, and
> resume the execution at P. Without the stack, this would be a royal pain
> to do (it is not impossible, but it is hard).

Wrong.
With the current implementation, you cannot easily do this,
since you have to crawl the C stack which is a no-no.
With Stackless, you can do it partially, since it involves
traversals of the frame chain only.
The dilemma is just, that Stackless still has C recursions
in a few places, and therefore, state saving is possible
for clean stackless frame chain parts only at the moment.

> There are plenty of application domains where the above scenario is
> needed: thread migration in distributed systems, fault-tolerancy in
> databases, etc.

Thank you for the argument! What you say means
"make stackless completely C recursion free", and
then we can do complete state pickling.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     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