[Stackless] Documentation of tasklet life cycle (was Re: Open Stackless issues)
richard.m.tew at gmail.com
Thu Sep 5 02:37:47 CEST 2013
Are you sure it wasn't you and I discussing channels and tasklets and
pickling years back, and we came to the conclusion you could detach a
tasklet from the channel it was blocked on, and pickle it as is. Then
unpickle it, make a new channel and attach it to that. I think it
used some hacky version of the pickling protocol (__reduce__ and
whatever the converse is), where you'd compose the tasklet queue and
then instantiate the channel that way with tasklets being sucked in.
On 9/5/13, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
> Hi Guys:
> This is great! Sorry about that. I am not sure why I was under that
> impression? Let me dredge out pickling code examples and see what I was
> From: Richard Tew <richard.m.tew at gmail.com>
> To: Andrew Francis <andrewfr_ice at yahoo.com>; The Stackless Python Mailing
> List <stackless at stackless.com>
> Cc: "a.kruis at science-computing.de" <a.kruis at science-computing.de>
> Sent: Wednesday, September 4, 2013 2:18 PM
> Subject: Re: [Stackless] Documentation of tasklet life cycle (was Re: Open
> Stackless issues)
> Tasklets blocked on channels can be pickled.
>>>> import stackless
>>>> c = stackless.channel()
>>>> def f(ct):
> ... print "in"
> ... ct.receive()
> ... print "out"
>>>> t = stackless.tasklet(f)(c)
>>>> import cPickle
>>>> s = cPickle.dumps(t)
> On 9/5/13, Andrew Francis <andrewfr_ice at yahoo.com> wrote:
>> Hi Anselm:
>> Message: 1
>> Date: Wed, 04 Sep 2013 15:07:51 +0200
>> From: Anselm Kruis <a.kruis at science-computing.de>
>> To: stackless at stackless.com
>> Subject: [Stackless] Documentation of tasklet life cycle (was Re: Open
>> Stackless issues)
>> Message-ID: <522730A7.3070900 at science-computing.de>
>> Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
>>>I just created a first draft of a state diagram for the tasklet life
>>>cycle. It is here:
>>>Any comments and suggestions are highly welcome.
>> Nice work. Some comments:
>> What is the difference between a tasklet that is not alive (i.e., not
>> to a callable) and a tasklet that is not alive (but bounded to a
>> Should there be a dead state?
>> Do you really need to distinguish between the "running" state and the
>> "running in scheduler" state? Isn't the difference between stackless.run()
>> and tasklet.run() a matter of when a tasklet is scheduled?
>> Does a tasklet that is pickled or blocked on a channel require a special
>> state (since a tasklet blocked on a channel cannot be pickled)?
More information about the Stackless