[Web-SIG] Proposal for asynchronous WSGI variant
Manlio Perillo
manlio_perillo at libero.it
Tue May 6 12:17:41 CEST 2008
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
More information about the Web-SIG
mailing list