Ah, I didn't pick that up when skimming the code :-) On Tue, Apr 9, 2013 at 9:25 PM, Kristján Valur Jónsson <[email protected]> wrote: > To clarify: The error handler is called in the context of the erroring > tasklet, before switching away from it or doing any cleanup. > Hence, stackless.getcurrent() and all other features are still available. > I've added a test-suite item to verify this. > > K > >> -----Original Message----- >> From: Kristján Valur Jónsson >> Sent: 9. apríl 2013 09:18 >> To: 'Richard Tew' >> Cc: The Stackless Python Mailing List >> Subject: RE: [Stackless] added tasklet.throw >> >> I don't think so. Stackless.getcurrent() is still available to be called. >> also, I don't see why the error_handler ought to be unique to a thread, any >> more than __taskelet__ and __channel__ are. >> However, if we desire a more fine-grained control, then I thihk subclassing >> the tasklet would be the right way to do this. >> K >> >> > -----Original Message----- >> > From: Richard Tew [mailto:[email protected]] >> > Sent: 8. apríl 2013 21:02 >> > To: Kristján Valur Jónsson >> > Cc: The Stackless Python Mailing List >> > Subject: Re: [Stackless] added tasklet.throw >> > >> > Is there any value in passing in the tasklet the exception happened >> > in, as the first argument of the error handler? >> > If every thread has a scheduler, should the error handler be stored in >> > the thread context? >> > >> > On Tue, Apr 9, 2013 at 6:02 AM, Kristján Valur Jónsson >> > <[email protected]> wrote: >> > > Done, check it out in the repo. >> > > >> > > >> > > > >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
