[Web-SIG] Could WSGI handle Asynchronous response?

[Phillip J. Eby]

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
>>>this:
><snip>
>>>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
>application returns.

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!)