[Web-SIG] Proposal for asynchronous WSGI variant

[Christopher Stawarz]

On May 6, 2008, at 6:17 AM, Manlio Perillo wrote:

> I'm glad to know that there are some other people interested in  
> asynchronous application, do you have seen my extensions to WSGI in  
> my module for Nginx?

Yes, I have, and I had your module in mind as a potential provider of  
the AWSGI interface.

> Note that in Nginx the request body is pre-read before the  
> application is called (in fact wsgi.input is either a cStringIO or  
> File object).

Although I didn't state it explicitly in my spec, my intention is for  
the server to be able to implement awsgi.input in any way it likes, as  
long as it provides a recv() method.  It's totally acceptable for the  
request body to be pre-read.

> Unfortunately there is a *big* usability problem: the extension is  
> based on a well specified feature of WSGI: the gateway can suspend  
> the execution of the WSGI application when it yields.
>
> However if the asynchronous code is present in a "child" function,  
> we have something like this:
> ...
> That is, all the functions in the "chain" have to yield, and is not  
> very good.

Yes, you're right.  However, if you're willing/able to use Python 2.5,  
you can use the new features of generators to implement a call stack  
that lets you call child functions and receive return values and  
exceptions from them.  I've implemented this in awsgiref.callstack.   
Have a look at

   http://pseudogreen.org/bzr/awsgiref/examples/echo_request_with_callstack.py

for an example of how it works.

> The solution is to use coroutines, and I'm planning to integrate  
> greenlets (from the pylib project) into the WSGI module for Nginx.

Interesting, but it's not clear to me how/if this would work.  Can you  
explain more or point me to some code?


Thanks,
Chris