[Web-SIG] Proposal for asynchronous WSGI variant
cstawarz at csail.mit.edu
Thu May 8 04:59:42 CEST 2008
On May 7, 2008, at 5:36 PM, Ionel Maries Cristian wrote:
> The way I see it asynchronous wsgi is just a matter of deciding how
> to handle the input asynchronously - a asynchronous input wsgi
> extension specification.
Another crucial element is the ability to perform non-blocking I/O on
other file descriptors (TCP connections to other servers, pipes to
other OS processes). This is why the readable/writable functions (or
something like them) are necessary.
> So I suggest completely dropping the idea of a incompatibility
> between async_wsgi and wsgi (since it doesn't help anyone in the
> long run really - it just fragments the gateway providers and
> overcomplicate things) and concentrate more on the async input
This is a compelling argument. As long as the application iterable
yields only strings (which, the more I think about it, seems like the
right thing to do), then the remaining functionality I propose can be
implemented as extensions to WSGI, perhaps in a "x-wsgiorg.async"
However, the problem remains that, even though an asynchronous server
can implement the write() callable and wsgi.input as required by the
WSGI spec, they effectively can't be used by applications, since they
involve potentially blocking I/O operations. So either WSGI has to be
revised to take the needs of asynchronous servers into account, or we
have to accept that async servers can never be fully WSGI compliant.
> So the idea is that the gateways would provide async input by
> default and a piece of middleware or config option to make it
> synchronous (well, actually, buffer it).
You mean the middleware would be used to make the input synchronous so
that an app that uses wsgi.input would function normally (reading from
the buffer)? That would fix the problem for wsgi.input, but the issue
with write() remains.
Another point to keep in mind is that in order to function correctly
on an async server, an application really has to be written with that
execution environment in mind. For example, an app couldn't use
httplib, since it does blocking I/O (which, again, would freeze up the
> Also, since there already are a bunch of async gateways out there I
> would like to hear if the other providers would/could implement the
> proposed form of common async input - that would ultimately decide
> the success of this proposed spec.
I would like to hear their opinions as well. In particular, do any
Twisted folks have comments on what we've discussed?
More information about the Web-SIG