On May 7, 2008, at 10:59 PM, Christopher Stawarz wrote:
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.
Maybe this isn't as big a deal as I'm making it. The point of the async extensions is to make it possible for WSGI apps to run effectively on asynchronous servers. Apps that use the extensions won't use write() or wsgi.input, so it really doesn't matter whether they're blocking or not.
Although apps that don't use the async extensions *could* be run on an asynchronous server (by using wsgi.input in a blocking fashion), doing so would mean that the server could effectively handle only one request at a time (i.e. serially). If this were unacceptable (which it most likely would be), then you just wouldn't do it. Better to use mod_wsgi or some other server that can run your app effectively.
So I guess the only issue is that authors of asynchronous servers who want to comply fully with the WSGI spec have to implement functionality (write() and wsgi.input) that can't be used without severely degrading the server's performance. But that's an issue that server authors can address as they see fit, not something that the WSGI spec needs to account for.
Thanks to everyone who has provided input so far -- please keep the comments coming! I'm going to work on another draft of my proposal that takes into account what we've discussed and will post it here when it's done.
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
