On Jan 5, 2010, at 4:53 PM, Terry Jones wrote: > I'm not sure if it's yet clear that I'm not trying *at all* to address > somehow stopping operations that are in progress. On the contrary, my code > always lets them run to their natural conclusion. It's just that if the > caller decides they're no longer interested in the result or that they want > the thing to fire right now, they can arrange for it. The originally called > code, including any err/callbacks that may be on the deferred it gave you, > is unaffected.
I understand what you're saying: you're interested in a subset of what I'm interested in, here. The point I'm trying to make is that once you've gone to the trouble of providing an API for *clients* of an operation to declare that they are no longer interested in its results, then it's wasteful for the underlying engine to continue executing the operation only to discard its result. I think that coming up with a good API and semantics for "I no longer care about the result here" has a huge amount of overlap with this anyway. I grant that it may well be easier to implement without worrying about the underlying operation though, and the semantics you've defined by explicitly ignoring the actually-stopping case are much simpler. But that also means that you still have to go to the trouble of figuring out when you're no longer interested in the result any more, but after going to the trobule ... what's the benefit? I know what the use-cases are for stopping the underlying operation (notifying the peer that you're not going to accept it, reclaiming the resources); but if you're just going to let the operation complete eventually anyway, why wouldn't you want to just finish processing the result when it arrives regardless? _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
