[Web-SIG] Could WSGI handle Asynchronous response?
Phillip J. Eby
pje at telecommunity.com
Tue Jul 29 03:21:18 CEST 2008
At 04:57 PM 7/28/2008 -0700, Donovan Preston wrote:
>On Jul 28, 2008, at 12:52 PM, Etienne Robillard wrote:
>>On Mon, 18 Feb 2008 04:23:38 -0800 (PST)
>>est <electronixtar at gmail.com> wrote:
>>>I am writing a small 'comet'-like app using flup, something like
>>>So is WSGI really synchronous? How can I handle asynchronous outputs
>>>with flup/WSGI ?
>WSGI says that the entire body should be written by the time the wsgi
No, it doesn't. It says that all your write() calls must be done by
then, which is not at all the same thing. If the application returns
an iterator, that iterator can keep yielding outputs until the
(figurative) cows come home.
> So yes it is really synchronous; as Manlio
>Perillo said in another message it is possible to abuse generators to
>allow a wsgi application to operate in the fashion you desire, but
>both the server and the application have to know how to do this and
>there is no standardization yet.
This is confusing asynchronous APIs, non-blocking behavior, and
streaming output. A WSGI application can avoid blocking the server
by yielding empty strings until it is ready to produce more
output. (This may not provide any performance benefit over sleep()
however, and may in some circumstances be worse.)
There is no async API that's part of WSGI itself, and it's unlikely
there will ever be one unless there ends up being an async API for
Python as well.
(By the way, using a generator to produce streaming output is not
abuse: it is the *intended* use of iterables in WSGI!)
More information about the Web-SIG