[Stackless] added tasklet.throw

Richard Tew richard.m.tew at gmail.com
Thu Apr 4 20:47:31 CEST 2013

On Fri, Apr 5, 2013 at 4:09 AM, Kristján Valur Jónsson <
kristjan at ccpgames.com> wrote:

>  I’ve been thinking some more about this. ****
> It should be ok to kill a tasklet that hasn’t run yet.  And killing a dead
> one should be a no-op.****
> Rather than making “kill” have special semantics, how about just applying
> that rule?  An exception sent to a tasklet that hasn´t run yet just
> disappears and the tasklet dies.****
> An exception sent to a dead tasklet just disappears.****
> I think these are sensible semantics.  In my opinion, it was a mistake to
> design stackless such that uncought tasklet exceptions were sent to the
> main tasklet.

I disagree.  I think there's an argument to be made that when a new tasklet
gets inserted into the scheduler, it is effectively running.  The user does
not know, or care, when it actually starts running as long as it duly gets
run in a fair manner.  My expectation would be that an exception raised on
a not yet run by (but inserted in) the scheduler tasklet, would be raised
on the main tasklet - as it has not been caught.  Also, I would expect that
raising an exception on a dead tasklet would error.

For the most part, I just start tasklets.  I expect them to run.  But when
I start micromanaging them and holding references to them to do more
advanced usage, I already do things like checking to see if they are alive
before performing operations on them.   Or checking to see if they are
blocked on a channel.  Or whatever.  I think that based on my usage of
tasklets, if someone is throwing exceptions on tasklets, they should be
explicit in terms of the expected situation.  This means that it is not
unreasonable to expect them to check the tasklets state before raising
exceptions on them.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20130405/3d94da49/attachment-0001.html>

More information about the Stackless mailing list