[Twisted-Python] How to safely stop a chain of deferreds
Hi, in a GUI application I'm using quite a comprehensive chain of deferreds and I'm running the mainloop from the glib2reactor. At a certain point of my application I need to terminate the entire chain of deferreds to make sure that no more data is loaded and processed. Stopping the reactor does not work as the entire GUI would terminate, too. I tried to cancel the first deferred, hoping that the cancel event will be forwarded to the next deferred in the chain or at least invoke an errback, but for some reason it does not work and the deferreds seem to run forever. Any ideas on how to solve this issue? Many thanks, -- tomw <tomw@ubilix.com>
On Tue, 2011-06-28 at 15:30 +0200, tomw wrote:
Unless you registered a cancellation function for the Deferreds, the best cancelling one can do is not pass you the results. So you'll need to register a canceller for the Deferred that is hooked up to the result of the original task (and any new Deferreds created along the chain).
On 28 Jun 2011, at 20:37, exarkun@twistedmatrix.com wrote:
Pretty much what everyone is insinuating is that: a) By your description it is not obvious what the application is doing, so a better description will be more helpful b) You are using incorrect terms, making even harder to give advice c) Callback chains don't have any built-in support for any kind of cancelling/stopping. d) Deferreds have a cancel method but it's up to the creator of the Deferred to provide any meaning to it Now, if you have a loop loading data and passing it to a chain of callbacks, and you'd need to stop mid-processing, the way I'd do that is to have a 'isStopped' boolean variable that can be set to True to initiate the stopping procedure. You will then stop loading any data and finish processing existing data. However, this is little more than a guess based upon my very vague understanding of the problem you are trying to describe. Orestis
On Tue, Jun 28, 2011 at 9:30 AM, tomw <tomw@ubilix.com> wrote:
Have you tried setting up appropriate callback functions and raising an Exception at the point where the callback chain should be terminated? Note that each errback should return the provided failure so that execution doesn't switch back to the callback side. See "Visual Explanation" in this document: http://twistedmatrix.com/documents/current/core/howto/defer.html Cheers, Jason
On Tue, 2011-06-28 at 15:30 +0200, tomw wrote:
Unless you registered a cancellation function for the Deferreds, the best cancelling one can do is not pass you the results. So you'll need to register a canceller for the Deferred that is hooked up to the result of the original task (and any new Deferreds created along the chain).
On 28 Jun 2011, at 20:37, exarkun@twistedmatrix.com wrote:
Pretty much what everyone is insinuating is that: a) By your description it is not obvious what the application is doing, so a better description will be more helpful b) You are using incorrect terms, making even harder to give advice c) Callback chains don't have any built-in support for any kind of cancelling/stopping. d) Deferreds have a cancel method but it's up to the creator of the Deferred to provide any meaning to it Now, if you have a loop loading data and passing it to a chain of callbacks, and you'd need to stop mid-processing, the way I'd do that is to have a 'isStopped' boolean variable that can be set to True to initiate the stopping procedure. You will then stop loading any data and finish processing existing data. However, this is little more than a guess based upon my very vague understanding of the problem you are trying to describe. Orestis
On Tue, Jun 28, 2011 at 9:30 AM, tomw <tomw@ubilix.com> wrote:
Have you tried setting up appropriate callback functions and raising an Exception at the point where the callback chain should be terminated? Note that each errback should return the provided failure so that execution doesn't switch back to the callback side. See "Visual Explanation" in this document: http://twistedmatrix.com/documents/current/core/howto/defer.html Cheers, Jason
participants (5)
-
exarkun＠twistedmatrix.com -
Itamar Turner-Trauring -
Jason Rennie -
Orestis Markou -
tomw