Stackless Python 1.0 + Continuations 0.6

Vladimir Marangozov Vladimir.Marangozov at inrialpes.fr
Wed Jan 26 09:59:48 EST 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
easier
in stackless, compared to stackfull Python, is a trap.

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

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

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



More information about the Python-list mailing list