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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
