Ø 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. Well, there are basically two issues at play:
1) Yes, it should behave as though it had not been caught. So, the tasklet should never run after this. It effectively kills it. 2) But the point I was trying to make and which I didn't quite make explicit was that I have grown to dislike how unhandled exceptions are automatically handed to the main tasklet. This makes it hard to write general tasklet code because one has to be aware of the special status of the main tasklet, and be prepared to handle uncaught exceptions from other tasklets everywhere. Contrast this with the way threads work, where uncaught exceptions are simply logged out. Because of this inconvenience, everyone ends up writing their own special tasklet boilerplate that ensures that exceptions are dealt with in some defined way. So, in retrospect, I think it was unwise to do this. And I think that if a new api is created, it should perhaps behave in a more sane manner :) As for dead tasklets, I don'k know. Is it an error to "kill" a dead tasklet? Perhaps we could treat it as an uncaught exception as well. But my main point is that it is not reasonable to have to worry about that whenever you call tasklet.throw(foo, bar) that you will have that exception raised for yourself. Perhaps a true/false value can be returned for a dead tasklet or something. But I don't think it is sensible semantics to have the possibility of the exception bouncing back at the caller, like currently raise_exception does. K From: [email protected] [mailto:[email protected]] On Behalf Of Richard Tew Sent: 4. apríl 2013 18:48 To: The Stackless Python Mailing List Subject: Re: [Stackless] added tasklet.throw On Fri, Apr 5, 2013 at 4:09 AM, Kristján Valur Jónsson <[email protected]<mailto:[email protected]>> wrote: 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
