<br><br><div class="gmail_quote">On Thu, Aug 16, 2012 at 3:42 PM, Idlecore <span dir="ltr"><<a href="mailto:xor@idlecore.com" target="_blank">xor@idlecore.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a protocol that calls code that spans several namespaces. At<br>
any of these namespaces there might be a deferred waiting to be<br>
called. The protocol can be disconnected at any time and I currently<br>
don't have a clean way to cancel all the potential deferreds from<br>
within the protocol.<br></blockquote><div><br>What do you mean by "namespaces"? If the Protocol called some code that returned a Deferred, the Protocol will then have a reference to it. If a callback function on that Deferred returns a Deferred, cancelling the original one will also cancel the chained Deferred if necessary (though you'll need to have a cancellation function for each, of course).<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Will the protocol stick around long enough after disconnection for the<br>
deferreds to eventually be called?<br></blockquote><div><br>The Protocol will have its connectionLost() method called when it disconnects; this is where you'd typically cancel any pending operations. If some other object has a reference to it, it will not be garbage collected until that reference is gone, as with any Python object. The pending operations will, however, continue (possibly wasting resources) unless you cancel them in response to the connectionLost() call. <br>
<br>Can you give a tiny code example, perhaps, demonstrating the kind of Deferred management problem you're having?<br><br></div></div>-- <br>Itamar Turner-Trauring, Future Foundries LLC<br><a href="http://futurefoundries.com/" target="_blank">http://futurefoundries.com/</a> — Twisted consulting, training and support.<br>
<br>