[Twisted-Python] Timing Out Deferreds
I've been trying to figure out an intelligent way of timing out deferreds. I'd like something like this... def myTimeoutMethod(...): ... d = whatnot() d.addCallback(...) d.addErrback(...) d.addTimeout(5, myTimeoutMethod) There are obvious problems with trying to interrupt an existing deferred, but I was hoping there might be just some way of discarding its data when it finally does return, or dereferencing the deferred object itself from the reactor, which might just let it clean itself up on its own. Thoughts? -Ken
On Feb 25, 2005, at 2:53 PM, Ken Kinder wrote:
I've been trying to figure out an intelligent way of timing out deferreds.
No, a deferred is just a chain of callbacks -- it doesn't really make sense to time out a chain of callbacks. You need to time out the *source* operation that is planning on eventually calling the deferred. The process of killing the source operation ought to additionally cause the deferred's errback to be called. James
James Y Knight wrote:
No, a deferred is just a chain of callbacks -- it doesn't really make sense to time out a chain of callbacks. You need to time out the *source* operation that is planning on eventually calling the deferred. The process of killing the source operation ought to additionally cause the deferred's errback to be called.
That would be ideal, but the situation I'm in isn't exactly that way. I have a general system of scheduling tasks that doesn't really know what the task is, but knows it shouldn't take too long -- something like a crontab.
On Mon, 2005-02-28 at 10:31 -0600, Ken Kinder wrote:
That would be ideal, but the situation I'm in isn't exactly that way. I have a general system of scheduling tasks that doesn't really know what the task is, but knows it shouldn't take too long -- something like a crontab.
How about having registration of a task also require a cancellation function? Which can be lambda:None, if it's not possible to do so.
participants (3)
-
Itamar Shtull-Trauring -
James Y Knight -
Ken Kinder