Stackless Python 1.0 + Continuations 0.6

Vladimir Marangozov Vladimir.Marangozov at
Wed Jan 26 15:59:48 CET 2000

Christian Tismer wrote:
> Gerald Klix wrote:
> >
> > Christian Tismer wrote:
> >
> > > Magnus Lie Hetland wrote:
> ...
> > > > would it be possible to stop and pickle a thread? This might be very
> > > > interesting for Mobile Agent Technology
> ...
> > Chris, please add this point to your arguments for stackless python!
> I did so. Beneath the PalmIII-opportunity, it seems to be
> a major argument. Thanks a lot!

Easy. Capturing the thread state, i.e. the execution stack + the set of
references within the stack pointing to existing (shared) objects, seems
to be a no brainer, but deducing from here that thread migration is
in stackless, compared to stackfull Python, is a trap.

Assuming that both versions of the interpreter have, at some point in
execution of a program, their thread state available for further
(be it check-pointing for an eventual future error recovery, or
serialization of the objects accessible from that state for an eventual
thread migration), I hardly see any argument why stackless is better,
to say any different, than stackfull Python. So thread migration is not
of an argument you could rely on... Capturing the full thread *state*

In case you have, in your thread state, a pointer to a dict, which
to contain the sys module, a strawman thread migration scheme would
the serialization of the whole interpreter...

Rest assured -- the 4k Palm argument has still a chance, though ;-)
       Vladimir MARANGOZOV          | Vladimir.Marangozov at | tel:(+33-4)76615277 fax:76615252

More information about the Python-list mailing list