At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
Earlier in this post I illustrated a few that directly apply to a
commercial application I am currently writing. I'll elaborate:
:: Image scaling would benefit from multi-processing (spreading the
load across cores). Also, only one sacle is immediately required
before returning the post-upload page: the thumbnail. The other
scales can be executed without halting the WSGI application's return.
:: Asset content extraction and indexing would benefit from
threading, and would also not require pausing the WSGI application.
:: Since most templating engines aren't streaming (see my unanswered
thread in the general mailing list re: this), pausing the
application pending a particularly difficult render is a boon to
single-threaded async servers, though true streaming templating
(with flush semantics) would be the holy grail. ;)
In all these cases, ISTM the benefit is the same if you future the
WSGI apps themselves (which is essentially what most current async
WSGI servers do, AFAIK).
:: Long-duration calls to non-async-aware libraries such as DB access.
The WSGI application could queue up a number of long DB queries,
pass the futures instances to the template, and the template could
then .result() (block) across them or yield them to be suspended and
resumed when the result is available.
:: True async is useful for WebSockets, which seem a far superior
solution to JSON/AJAX polling in addition to allowing real web-based
socket access, of course.
The point as it relates to WSGI, though, is that there are plenty of
mature async APIs that offer these benefits, and some of them (e.g.
Eventlet and Gevent) do so while allowing blocking-style code to be
written. That is, you just make what looks like a blocking call, but
the underlying framework silently suspends your code, without tying
up the thread.
Or, if you can't use a greenlet-based framework, you can use a
yield-based framework. Or, if for some reason you really wanted to
write continuation-passing style code, you could just use the raw Twisted API.
But in all of these cases you would be better off than if you used a
half-implementation of the same thing using futures under WSGI,
because all of those frameworks already have mature and sophisticated
APIs for doing async communications and DB access. If you try to do
it with WSGI under the guise of "portability", all this means is that
you are stuck rolling your own replacements for those existing APIs.
Even if you've already written a bunch of code using raw sockets and
want to make it asynchronous, Eventlet and Gevent actually let you
load a compatibility module that makes it all work, by replacing the
socket API with an exact duplicate that secretly suspends your code
whenever a socket operation would block.
IOW, if you are writing a truly async application, you'd almost have
to be crazy to want to try to do it *portably*, vs. picking a
full-featured async API and server suite to code against. And if
you're migrating an existing, previously-synchronous WSGI app to
being asynchronous, the obvious thing to do would just be to grab a
copy of Eventlet or Gevent and import the appropriate compatibility
modules, not rewrite the whole thing to use futures.
_______________________________________________
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
