On Fri, Apr 5, 2013 at 4:09 AM, Kristján Valur Jónsson < [email protected]> 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. Cheers, Richard.
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
