[Python-ideas] The async API of the future: Twisted and Deferreds
ben at bendarnell.com
Sat Oct 13 07:26:46 CEST 2012
On Fri, Oct 12, 2012 at 4:39 PM, Richard Oudkerk <shibturn at gmail.com> wrote:
>> def view_paste_async(request, filekey):
>> # Create Futures -- no yields!
>> f1 = Pastes.objects.get_async(key=filekey) # This won't raise
>> f2 = loader.get_template_async('pastebin/error.html')
>> f3 = loader.get_template_async('pastebin/paste.html')
>> fileinfo= yield f1
>> except DoesNotExist:
>> t = yield f2
>> return HttpResponse(t.render(Context(dict(error='File does not
>> f = yield open_async(fileinfo.filename)
>> fcontents = yield f.read_async()
>> t = yield f3
>> return HttpResponse(t.render(Context(dict(file=fcontents))))
> So would the futures be registered with the reactor as soon as they are
> created, or only when they are yielded? I can't see how there can be any
> "concurrency" if they don't start till they are yielded. It would be like
The Futures are not what is doing the work here, they just hold the
result. In this example the get_async() functions register something
with the reactor when they are called. When that "something" is done
(or perhaps after several "somethings" chained together), get_async
will set a result on its Future.
> But if the futures are registered immediately with the reactor then does
> that mean there is a singleton reactor? That seems rather inflexible.
In most event-driven systems there is a global (or thread-local) event
loop, but it's also possible to pass one in explicitly to get_async().
More information about the Python-ideas