[Web-SIG] Proposal for asynchronous WSGI variant

[Manlio Perillo]

Christopher Stawarz ha scritto:
> (I'm new to the list, so please forgive me for making my first post a
> specification proposal :)
> 
> Browsing through the list archives, I see there's been some
> inconclusive discussions on adding better support for asynchronous web
> servers to the WSGI spec.  Since such support would be very useful for
> some upcoming projects of mine, I decided to take a shot at specing
> out and implementing it.  I'd be grateful for any feedback you have.
> If this seems like something worth pursuing, I would also welcome
> collaborators to help develop the spec further.
> 

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?

The extension is documented here:
http://hg.mperillo.ath.cx/nginx/mod_wsgi/file/tip/README

see the Extensions chapter.

For some examples:
http://hg.mperillo.ath.cx/nginx/mod_wsgi/file/tip/examples/nginx-postgres-async.py
http://hg.mperillo.ath.cx/nginx/mod_wsgi/file/tip/examples/nginx-poll-sleep.py

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


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:

def application(environ, start_response):
    def nested():
       while True:
          poll(xxx)
          yield ''

       yield result


    for r in nested():
       if not r:
           yield ''

    yield r


That is, all the functions in the "chain" have to yield, and is not very 
good.


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


 > [...]



Regards   Manlio Perillo