[Stackless] added tasklet.throw

Christian Tismer tismer at stackless.com
Fri Apr 5 15:09:39 CEST 2013

On 04.04.13 20:47, Richard Tew wrote:
> On Fri, Apr 5, 2013 at 4:09 AM, Kristján Valur Jónsson 
> <kristjan at ccpgames.com <mailto: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.

I'm in the same boat.
Letting things just pass trough as a no-op is error-prone, because
it hides programming errors where an alive tasklet is expected,
but it was dead.
I believe it is better to support explicitly the expected situation instead
of making things too "handy", meaning sloppy style.
Fiddling around with tasklets is anyway not a feature that should
normally be used by users, so it is probably used in a framework.
But there things should be clean and unambiguous, to avoid hard to
track errors.

cheers - chris

Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/

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

More information about the Stackless mailing list