Python 2.0 and Stackless

[Shae Erisson]

Vladimir Marangozov wrote:

<bits snipped>

> 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).
> 
> There are plenty of application domains where the above scenario is
> needed: thread migration in distributed systems, fault-tolerancy in
> databases, etc.

I would argue that serialization of continuations/microthreads would be
worth it.
Pyro can distribute any picklable data type between VMs. If
continuations were picklable (1?) you could happily distribute your
tasks among VMs, whether they were running on different processors in a
single SMP machine, or separate computers in a network.

> Indeed. Nobody is against it. Some of us are conservative, though,
> and would like to weight the pros and cons before adopting a core
> feature. We've agreed that PEPs are the way to do it, because they
> summarize the issue with all pros & cons, helping people to emit
> opinions. This hasn't been done for Stackless. Do you volunteer to
> PEP it? Conservativeness is sometimes due to lack of detailed
> information, so a Stackless PEP mey well change popular beliefs
> on both sides.

To me at least, it's worth putting in the effort. All those in favor
jump in :)


(1) what do you call this anyway? pickle-able? picklable? implements the
pickle interface?
-- 
Shae Matijs Erisson - http://www.webwitches.com/~shae/
VirtualPairProgramming Wanted - Linux/Emacs/Python/Speak Freely
.fi: rakastan ohjelmointia - python kengittää aasia