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
_______________________________________________
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
