...

...

...

...

"Tristan" == Tristan Seligmann <mithrandi@mithrandi.net> writes:

Tristan> 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.

Tristan> The thing is, this attitude isn't always reasonable. Yes, I was being a bit deliberately flippant, and was speaking in the context of deferred processing. Reading through http://twistedmatrix.com/trac/ticket/990 there are lots of issues. It feels to me like it's too complicated to tackle in a clean / simple manner inside the Deferred class. Tristan> Deferred is not necessarily the place to implement cancellation, Tristan> but I think the idiom itself is important. Yes, agreed. Tristan> But, consider something like the transfer of a 512 TB file; Tristan> cancellation /is/ possible, through closing the TCP connection, Tristan> and the operation is significantly expensive, so "just forget it Tristan> and let it finish" is a somewhat cavalier attitude to take. I didn't mean to imply that cancellation isn't important or isn't possible etc. Tristan> I would imagine that you would errback the deferred in the general Tristan> case of cancellation; if your callback chain doesn't handle Tristan> errors, well... Yes, you'd see an exception just as you would if some other error happened. But errbacking the deferred is just one option. You can also callback it or, in the most recent code I posted, just tell the deferred to never fire. They're all options. The point is to give the caller those options. Terry