On Tue, Jan 5, 2010 at 6:29 AM, Terry Jones <terry@jon.es> wrote:
- 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.
The thing is, this attitude isn't always reasonable. Deferred is not necessarily the place to implement cancellation, but I think the idiom itself is important. Certainly there are some operations where cancellation is not feasible; perhaps because the underlying APIs do not support cancellation, or because allowing the operation to complete is quicker/easier than trying to interrupt it. But, consider something like the transfer of a 512 TB file; cancellation /is/ possible, through closing the TCP connection, and the operation is significantly expensive, so "just forget it and let it finish" is a somewhat cavalier attitude to take.
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).
I would imagine that you would errback the deferred in the general case of cancellation; if your callback chain doesn't handle errors, well... -- mithrandi, i Ainil en-Balandor, a faer Ambar