Hi Jason, In general I want to tread very carefully with changes to Tulip cancellation -- this is an area full of subtleties, and the design has changed dramatically during the later stages of Tulip's design.
Re 1: I'm not sure I follow. Have you found specific code in Tulip that suppresses logging of cancellation? If so, are you sure you are hitting this code? Or do you at least have example code that appears to indicate this is the case? Is it perhaps the case that what you are seeing is a cancel() call being ignored because the Future/Task being cancelled is already completed? Re 2: I suppose there are some philosophical differences between cancellation Tulip and abort in Kaa. Does Kaa support Futures that aren't tied to a coroutine? (The Future class in Tulip has no coroutine -- only its Task subclass does.) What do you suppose should happen to a non-Task Future when it gets cancelled? There's a zen of Python line that could possibly apply: "If the implementation is easy to explain, it may be a good idea." So if you can come up with a patch that looks particularly clean and elegant you may convince me. --Guido On Sun, May 25, 2014 at 12:06 PM, Jason Tackaberry <[email protected]> wrote: > Hi all, > > I am porting an application previously written using a little-known > framework called Kaa [1] to Tulip. There are a couple areas of surprise > around cancellation that I wanted to ask about: > > > 1. Cancellations are silent. > > Normally unhandled asynchronous exceptions are logged by the default > exception handler. Cancellations appear to be exempt, and although > CancelledError of a subtask does bubble up through the call stack, > unlike other uncaught asynchronous exceptions, logging is suppressed. > > I find this surprising. Now that surprise could just be that with Kaa I > made a conscious design decision that cancellations must be explicitly > caught and uncaught cancellations would be noisy. I think this fits > better with Python's zen (notably explicit is better than implicit). > > Was silent cancellation a specific design choice with tulip? > > > 2. Custom cancellation exceptions are impossible. > > One feature of kaa that I use in my application is the ability to abort > (or cancel, in tulip's lingo) a coroutine with a custom exception. [2] > This lets the canceller pass information into the coroutine and up the > stack about why the coroutine was cancelled. > > In my particular use case, I have a notion of a soft abort and a hard > abort, which triggers different logic by a coroutine higher up the > stack. An outside observer task which tracks overall progress will > either do a hard or soft abort depending on some condition. > > I'd propose something similar to what Kaa does: be able to pass an > optional custom exception object to cancel() which is raised inside the > coroutine and up the stack. The custom exception would need to subclass > CancelledError. > > Thoughts? I am happy to submit a patch if there's agreement that this > is a good idea. (Obviously I think it is. :)) > > > Thanks! > Jason. > > [1] http://api.freevo.org/kaa-base/index.html > [2] > http://api.freevo.org/kaa-base/async/inprogress.html#kaa.InProgress.abort > -- --Guido van Rossum (python.org/~guido)
