[Stackless] pickling & killing

Giovanni Bajo giovannibajo at libero.it
Mon Sep 29 12:13:28 CEST 2003


On Monday, September 29, 2003 1:27 AM [GMT+1=CET],
Christian Tismer <tismer at tismer.com> wrote:

>> Does it mean that it does start the next one EVEN IF self.t is not
>> the current one?
>> Why is that? I would think there is no reason for this to happen. If
>> I'm running tasklet A and I kill tasklet B, there is no apparent
>> reason to switch away from A. This is surely unexpected for me.

> [...]
> You want it to stick with the current tasklet?
> I can do that. You must know this is quite young stuff
> and has not been used so much.
> What I can provide rather easily:
> I cannot avoid to switch the tasklets at all. I must run the
> tasklet to be killed with an exception.
> But I can of course shuffle the task list in a way, that the
> next tasklet to be run after killing is the one that
> issued the kill.
> Do you want me to do that?

I have some doubts, see below...

>> I think I see the technical reason: kill() raises an exception in
>> the task, so the task is immediatly activated. If the exception is
>> not caught, the tasklet dies and the next one in the chain is
>> activated. But why should kill() switch immediatly to the task we
>> raised the exception into?
>
> I think you want the kill() be done immediately, no?
> If we want to kill(), we need to activate the tasklet,
> so it receives the exception.
> You want the killer to stay in control, so I have to
> make sure that it is reactivated right after that.
> I cannot guarantee it, since the tasklet to be killed might
> intercept the exception and do something else, but the general
> case should be quite easy.

That's the point.
kill() needs to run the tasklet to have it exit. This is not a problem
per-se, but when you write t.kill(), you surely don't expect the current
tasklet to be switched away. On the other hand, you really expect kill() to
take action immediatly. Otherwise, some very straightforward code like:

assert stackless.runcount == 1
t = tasklet(blah)()
t.kill()
assert stackless.runcount == 1

would fail, in a rather unexpected way. Thus, shuffling the list is probably
the best way to fix this problem. It would break only programs that rely on
the tasklet list order: for this, I think it's enough if you document that
the list order is subject to internal changes, and there is no guarantee it
will not change. I'd say, go for it.

Even better: do people really need to be able to access next/prev for each
tasklet? To me, stackless.getalltasklets() returning a list of all the
active tasklets would be enough.

tasklets = stackless.getalltasklets()
for t in tasklets:
    t.kill()

>>> this = stackless.current
>>> while stackless.runcount > 1:
>>>   this.next.kill()
>>
>> Again, thanks for this snippet, is really helpful to me.
>
> Sorry about this! These things are so obvious for me that
> I forget to document them. Will happen pretty soon.

Yup, stackless would really deserve a better documentation (and an updated
website). I'm sure you want them as well.

> Right now, I'm trying to patch kill() for you, in the way
> you need it.
> Actually, I'm asking myself, whether this should be done
> this way for all exceptions (changing raise_exception
> accordingly), or just for the kill case?

I think we have two different options here. Either we use the same behaviour
for both raise_exception and kill, or we just make it so that
raise_exception doesn't switch at all, and just "enqueue" the exception
until the tasklet is run next time.

By the way, TaskletExit is a global name. Shouldn't it be in the stackless
module just like everything else?

Giovanni Bajo





More information about the Stackless mailing list