On Tue, Jan 5, 2010 at 6:29 AM, Terry Jones <te...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
