[Web-SIG] Proposed WSGI extensions for asynchronous servers
cstawarz at csail.mit.edu
Tue May 13 00:18:47 CEST 2008
On May 12, 2008, at 5:07 PM, James Y Knight wrote:
> Surely you need DNS lookup to make a socket connection? Do you mean
> to provide that in an external library via a threadpool?
No, I don't mean to, because I don't care enough to bother. But if
you or someone else did, you'd be free to.
> You do need a framework. Using socket functions correctly (and
> portably) in non-blocking mode is not trivial.
I need a library, not a framework. And I may not even need to write
it myself. (For example, for making HTTP requests, I can use pycurl.)
> 1) Using apache is certainly a valid option performance-wise. Apache
> is pretty fast (obviously not the fastest server ever, but pretty
> good...). So if it has the features/packaging you need, by all
> means, use it. The advantage IMO of python servers is that they're
> lighter-weight deployment-wise and more easily configurable by code.
Fair enough. But I'm specifically interested in doing non-blocking I/
O on an asynchronous server.
> 2) If your app uses a database, you probably might as well just run
> it in a thread, because you're most likely going to use a blocking
> database API anyhow.
Yes, the compatibility of database and other API's with an
asynchronous execution model is important. Some (like MySQL) don't
support non-blocking connections, so you'd have to work around that
with threads or some other technique. Others (like PostgreSQL) do
provide an async API, which could be used with my proposed
extensions. (Manlio Perillo has an example of how this works with his
nginx mod_wsgi module at http://hg.mperillo.ath.cx/nginx/mod_wsgi/file/tip/examples/nginx-postgres-async.py.)
This is another issue you have to worry about to keep your app non-
blocking, but I don't think it's an insurmountable one. And again,
any library you develop to support these operations, written in terms
of the proposed non-blocking I/O extensions, will be usable on any
server that supports the extensions.
> 3) If your app does not make use of outgoing sockets, then
> 3a) If it also doesn't use wsgi.input, you could inform the WSGI
> server that it can just run the app not in a thread as it won't be
> 3b) If it does use wsgi.input, but doesn't need to read it
> incrementally, you could inform the server that it should pre-read
> the input and then run the app directly, not in a thread, as it
> won't be blocking.
> If none of the above apply, that is: you do not use a database, you
> do use incremental reading of wsgi.input, or an outgoing socket
> connection, /then/ an async WSGI extension might be useful. I claim
> that will cover a small subset of WSGI apps.
As I mentioned above, the database issue is a real one, but it can be
dealt with. I would like to be able to allow incremental reading of
wsgi.input, but I don't see how to do this without breaking
middleware. (If you have suggestions, please let me know.) As for
outgoing socket connections, I'm willing to accept the cost of a DNS
lookup; if someone else isn't, then they're free to write some kind of
local lookup server that their app talks to over a socket, and other
applications running on other servers can enjoy the fruits of their
I regret calling my proposal "Extensions for Asynchronous Servers",
since clearly that encompasses a much broader range of functionality
for you than it does for me. All I'm interested in is the ability to
poll file descriptors (and the things that allows me to do), and in
the next revision of my proposal I'll strive to make that clear. If
you have an application that requires functionality beyond that, then
my proposal won't be sufficient for your needs.
More information about the Web-SIG