Hi Glyph I read through http://twistedmatrix.com/trac/ticket/990 without trying to get all the details (some are not relevant to me, see below). I'll make a few comments here, then continue in the ticket, supposing there's interest. - It would simplify things to separate discussion of canceling deferreds from discussion of timeouts, which I think you were saying too. The timeout issue seemed to fade in that ticket, which is good. The stuff I posted is just about cancelation, nothing to do with timeouts. - Deferreds are fairly simple, would be good to keep them that way (i.e., not add to the class). Deferreds are very general, you can use them as building blocks to do more complex things, which is what my class does - it's just a deferred in the middle. - Once someone has made a function call, gotten a deferred, added call/errbacks to it, etc., it's gone. It's in flight. Forget about it. Relax and let it happen, etc. It's too complicated to try to stop things from happening that someone else set up to happen in some potentially complex manner. Other code, that the Deferred class itself can't possibly be aware of, may be relying on the deferred firing and at least part of its callback chain being run, etc. The simplest thing to do is to just provide a mechanism whereby the eventual holder of the deferred can opt to trigger their deferred immediately and ignore the final result of the original call (supposing there ever is one). - My class seems a bit like the Operation class proposed by Peaker. But it's simpler because you still only work with normal deferreds. You just get to fire a deferred any time you want to, with any value you want, and to ignore what would have been the result had you not preempively fired it. Those are some reactions to the thread. I'm happy to continue there. Terry