On Jan 6, 2010, at 5:23 AM, Glyph Lefkowitz wrote:
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?
Please forgive an old real-time jock here, but one way of handling this, and yes, I know how nasty, dirty, and ugly it is, is to patch the response chain so that all further notifications route to an ABORT handler that explicitly knows the details of how to clean old things up and stop new things from happening. I have had to use a mechanism like this in multi-processor, low bandwidth, high priority systems where a corrupted message can not be allowed to propagate and use up bandwidth or processor time that could be used to regenerate a correct message (think naval guidance system where one or more transducers just stopped working properly, like, got hit by a torpedo or started taking on sea water under pressure) Obviously, this is very radical and the ABORT handler needs to be completely aware of exactly how to interrupt all things in the chain properly in all possible states, but if it's that important that the process be interrupted, then it is. As far as I know, in my limited spelunking into Twisted's guts, Deferred's pretty much only know about themselves and their callbacks so I'm not sure whether there's a "ringmaster" that knows any more than that that could make sure that all things are cleaned up properly. S