[Web-SIG] Proposal for asynchronous WSGI variant

[Christopher Stawarz]

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