[Twisted-Python] How to deal with deferreds across several layers of namespaces?
I have a protocol that calls code that spans several namespaces. At any of these namespaces there might be a deferred waiting to be called. The protocol can be disconnected at any time and I currently don't have a clean way to cancel all the potential deferreds from within the protocol. Will the protocol stick around long enough after disconnection for the deferreds to eventually be called? Should I create a central deferred list, at the cost of having to access it through several layers of namespaces on other parts of my project? Is there a simple way of doing this? Regards, Pedro Azevedo
On Thu, Aug 16, 2012 at 3:42 PM, Idlecore <xor@idlecore.com> wrote:
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).
Will the protocol stick around long enough after disconnection for the deferreds to eventually be called?
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. Can you give a tiny code example, perhaps, demonstrating the kind of Deferred management problem you're having? -- Itamar Turner-Trauring, Future Foundries LLC http://futurefoundries.com/ — Twisted consulting, training and support.
On Thu, Aug 16, 2012 at 3:42 PM, Idlecore <xor@idlecore.com> wrote:
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).
Will the protocol stick around long enough after disconnection for the deferreds to eventually be called?
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. Can you give a tiny code example, perhaps, demonstrating the kind of Deferred management problem you're having? -- Itamar Turner-Trauring, Future Foundries LLC http://futurefoundries.com/ — Twisted consulting, training and support.
participants (2)
-
Idlecore -
Itamar Turner-Trauring