~hudson-openstack/nova/trunk

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'><html lang="en" xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Twisted Documentation: Asynchronous Responses (via Deferred)</title>

</head>

<h1 class="title">Asynchronous Responses (via Deferred)</h1>

The previous example had a <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.web.resource.Resource.html" title="twisted.web.resource.Resource">Resource</a></code> that generates its response

asynchronously rather than immediately upon the call to its render

method. Though it was a useful demonstration of the <code>NOT_DONE_YET</code>

feature of Twisted Web, the example didn't reflect what a realistic application

might want to do. This example introduces <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.defer.Deferred.html" title="twisted.internet.defer.Deferred">Deferred</a></code>, the Twisted class which is used

to provide a uniform interface to many asynchronous events, and shows you an

example of using a <code>Deferred</code>-returning API to generate an

asynchronous response to a request in Twisted Web.

<code>Deferred</code> is the result of two consequences of the asynchronous

programming approach. First, asynchronous code is frequently (if not always)

concerned with some data (in Python, an object) which is not yet available but

which probably will be soon. Asynchronous code needs a way to define what will

be done to the object once it does exist. It also needs a way to define how to

handle errors in the creation or acquisition of that object. These two needs are

satisfied by the callbacks and errbacks of a

<code>Deferred</code>. Callbacks are added to a <code>Deferred</code> with <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.defer.Deferred.addCallback.html" title="twisted.internet.defer.Deferred.addCallback">Deferred.addCallback</a></code>; errbacks

are added with <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.defer.Deferred.addErrback.html" title="twisted.internet.defer.Deferred.addErrback">Deferred.addErrback</a></code>. When the object

finally does exist, it is passed to <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.defer.Deferred.callback.html" title="twisted.internet.defer.Deferred.callback">Deferred.callback</a></code> which passes it on to the

callback added with <code>addCallback</code>. Similarly, if an error occurs,

<code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.defer.Deferred.errback.html" title="twisted.internet.defer.Deferred.errback">Deferred.errback</a></code> is

called and the error is passed along to the errback added with

<code>addErrback</code>. Second, the events that make asynchronous code actually

work often take many different, incompatible forms. <code>Deferred</code> acts

as the uniform interface which lets different parts of an asynchronous

application interact and isolates them from implementation details they

shouldn't be concerned with.

That's almost all there is to Deferred. To solidify your new understanding,

now consider this rewritten version of DelayedResource which uses a

Deferred-based delay API. It does exactly the same thing as the <a href="asynchronous.html" shape="rect">previous example</a>. Only the implementation is

different.

First, the example must import that new API that was just mentioned, <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.task.deferLater.html" title="twisted.internet.task.deferLater">deferLater</a></code>:

<pre class="python">1

from twisted.internet.task import deferLater

</pre>

Next, all the other imports (these are the same as last time):

<pre class="python">1

from twisted.web.resource import Resource

from twisted.web.server import NOT_DONE_YET

from twisted.internet import reactor

</pre>

With the imports done, here's the first part of the

<code>DelayedResource</code> implementation. Again, this part of the code is

identical to the previous version:

<pre class="python">1

class DelayedResource(Resource):

def _delayedRender(self, request):

request.write("Sorry to keep you waiting.")

request.finish()

</pre>

Next we need to define the render method. Here's where things change a

bit. Instead of using <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.interfaces.IReactorTime.callLater.html" title="twisted.internet.interfaces.IReactorTime.callLater">callLater</a></code>, We're going to

use <code class="API"><a href="http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.task.deferLater.html" title="twisted.internet.task.deferLater">deferLater</a></code> this

time. <code>deferLater</code> accepts a reactor, delay (in seconds, as with

<code>callLater</code>), and a function to call after the delay to produce that

elusive object discussed in the description of Deferreds. We're also going to

use <code>_delayedRender</code> as the callback to add to the

<code>Deferred</code> returned by <code>deferLater</code>. Since it expects the

request object as an argument, we're going to set up the <code>deferLater</code>

call to return a <code>Deferred</code> which has the request object as its

result.

<pre class="python">1

def render_GET(self, request):

d = deferLater(reactor, 5, lambda: request)

</pre>

The <code>Deferred</code> referenced by <code>d</code> now needs to have the

<code>_delayedRender</code> callback added to it. Once this is done,

<code>_delayedRender</code> will be called with the result of <code>d</code>

(which will be <code>request</code>, of course — the result of <code>(lambda:

request)()</code>).

100

<pre class="python">1

101

d.addCallback(self._delayedRender)

102

</pre>

103

104

Finally, the render method still needs to return <code>NOT_DONE_YET</code>,

105

for exactly the same reasons as it did in the previous version of the

106

example.

107

108

<pre class="python">1

109

return NOT_DONE_YET

110

</pre>

111

112

And with that, <code>DelayedResource</code> is now implemented based on a

113

<code>Deferred</code>. The example still isn't very realistic, but remember that

114

since Deferreds offer a uniform interface to many different asynchronous event

115

sources, this code now resembles a real application even more closely; you could

116

easily replace <code>deferLater</code> with another

117

<code>Deferred</code>-returning API and suddenly you might have a resource that

118

does something useful.

119

120

Finally, here's the complete, uninterrupted example source, as an rpy script:

121

122

<pre class="python"> 1

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

from twisted.web.resource import Resource

140

141

142

143

class DelayedResource(Resource):

144

def _delayedRender(self, request):

145

request.write("Sorry to keep you waiting.")

146

request.finish()

147

148

def render_GET(self, request):

149

150

d.addCallback(self._delayedRender)

151

return NOT_DONE_YET

152

153

resource = DelayedResource()

154

</pre>

155

156

</div>

157

158

<a href="../index.html">Index</a>

159

Version: 10.0.0

160

</body>

161

</html>

b'\\ No newline at end of file'

Older »