[Web-SIG] Proposed WSGI extensions for asynchronous servers

[James Y Knight]

On May 12, 2008, at 2:55 PM, Christopher Stawarz wrote:

>
>> There are other issues. How do you do a DNS lookup? How do you get  
>> process completion notification? Heck, how do you run a process?
>
> These are valid questions that I'm not attempting to address with  
> this proposal.  So maybe the title of my spec should be "Extensions  
> for Asynchronous I/O", since that's the only issue it deals with.  I  
> see these other issues as something for other specifications to  
> address.

Surely you need DNS lookup to make a socket connection? Do you mean to  
provide that in an external library via a threadpool?

> No, you don't need a whole new framework.  You need libraries (for  
> making HTTP requests, talking to databases, etc.) that are written  
> to use the extensions the spec provides.  These only need to be  
> written once and can then be used with *any* server that supports  
> the extensions.

You do need a framework. Using socket functions correctly (and  
portably) in non-blocking mode is not trivial.

>> Well, my claim would be that it's usually acceptable. Certainly  
>> sometimes it's not, which is where the use of an asynchronous  
>> server framework comes in handy.
>
> I don't get how it's acceptable.  If you spawn a separate thread for  
> each request, then your server is no longer asynchronous.  At that  
> point, why not just save yourself some trouble and use Apache?

Well,

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.
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.
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  
blocking.
  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.

James