[Twisted-Python] Adding callback to a Deferred that's already running?
Mike C. Fletcher
mcfletch at rogers.com
Wed Aug 25 23:15:13 MDT 2004
Steve Freitas wrote:
>Hi all,
>
>I've got an XML-RPC app that has to grab some data from a SQL database, then
>depending on the results, make some more SQL calls, make some more decisions,
>then finally return a result. So, I'm hip-deep in Deferreds. So, here's the
>idiom I've come up with, and I'm running into a limitation with it, namely
>that I can't seem to add callbacks to a Deferred after it has started
>running. Here's what I'm doing in abbreviated form, and it's an idiom I'd
>like to stick with, if possible:
>
>
This wasn't spectacularly obvious to me the first time either, but I
think it's covered somewhere in the deferred execution howto; in your
callback/errback, return a new deferred and the processing of the
deferred chain will pause until that new deferred fires. Here's an
example of code that does that...
df = self.shouldRetrieve( urlRecord )
def ifWeShould( judgement, urlRecord ):
if judgement:
df = urlRecord.retrieve( self.timeout, self.userAgent )
df.addCallback( self.onSuccess, urlRecord = urlRecord )
df.addErrback( self.onFailure, urlRecord = urlRecord )
return df
else:
return self.onFailure(
failure.Failure( RobotDenied(urlRecord)),
urlRecord = urlRecord
)
df.addCallback( ifWeShould, urlRecord=urlRecord )
In the one branch, we return the result of a call, in the other, we
return a new Deferred. Note that the new deferred shows up between the
current callback and any Deferred higher up in the chain, so the
Deferred's higher up the chain will get the result of the new Deferred.
If that's not desirable, you can define a handler for the new deferred
that returns the original result.
Hope I understood the question properly and that this helped,
Mike
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
More information about the Twisted-Python
mailing list