07.01.2011 07:24, Alex Grönholm kirjoitti:
07.01.2011 06:49, P.J. Eby kirjoitti:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems to have won out in the broader scope.
Do any established async frameworks or server (e.g. Twisted,
Eventlet, Gevent, Tornado, etc.) make use of futures?
I understand that Twisted has incorporated futures support to their
deferreds. Others, I believe, don't support them yet. You have to
consider that Python 3.2 (the first Python with futures support in
stdlib) hasn't even been released yet, and it's only been two weeks
since I released the drop-in backport
(http://pypi.python.org/pypi/futures/2.1).
Exarkun corrected me on this -- there is currently no futures support in
Twisted. Sorry about the false information.
Having a ratified and incorporated language PEP (core in 3.2 w/
compatibility package for 2.5 or 2.6+ support) reduces the scope of
async discussion down to: "how do we integrate futures into WSGI 2"
instead of "how do we define an async API at all".
It would be helpful if you addressed the issue of scope, i.e., what
features are you proposing to offer to the application developer.
While the idea of using futures presents some intriguing
possibilities, it seems to me at first glance that all it will do is
move the point where the work gets done. That is, instead of simply
running the app in a worker, the app will be farming out work to
futures. But if this is so, then why doesn't the server just farm
the apps themselves out to workers?
I guess what I'm saying is, I haven't heard use cases for this from
the application developer POV -- why should an app developer care
about having their app run asynchronously?
Applications need to be asynchronous to work on a single threaded
server. There is no other benefit than speed and concurrency, and
having to program a web app to operate asynchronously can be a pain.
AFAIK there is no other way if you want to avoid the context switching
overhead and support a huge number of concurrent connections.
Thread/process pools are only necessary in an asynchronous application
where the app needs to use blocking network APIs or do heavy
computation, and such uses can unfortunately present a bottleneck. It
follows that it's pretty pointless to have an asynchronous application
that uses a thread/process pool on every request.
The goal here is to define a common API for these mutually
incompatible asynchronous servers to implement so that you could one
day run an asynchronous app on Twisted, Tornado, or whatever without
modifications.
So far, I believe you're the second major proponent (i.e. ones with
concrete proposals and/or implementations to discuss) of an async
protocol... and what you have in common with the other proponent is
that you happen to have written an async server that would benefit
from having apps operating asynchronously. ;-)
I find it hard to imagine an app developer wanting to do something
asynchronously for which they would not want to use one of the
big-dog asynchronous frameworks. (Especially if their app involves
database access, or other communications protocols.)
This doesn't mean I think having a futures API is a bad thing, but
ISTM that a futures extension to WSGI 1 could be defined right now
using an x-wsgi-org extension in that case... and you could then
find out how many people are actually interested in using it.
Mainly, though, what I see is people using the futures thing to
shuffle off compute-intensive tasks... but if they do that, then
they're basically trying to make the server's life easier... but
under the existing spec, any truly async server implementing WSGI is
going to run the *app* in a "future" of some sort already...
Which means that the net result is that putting in async is like
saying to the app developer: "hey, you know this thing that you just
could do in WSGI 1 and the server would take care of it for you?
Well, now you can manage that complexity by yourself! Isn't that
wonderful?" ;-)
I could be wrong of course, but I'd like to see what concrete use
cases people have for async. We dropped the first discussion of
async six years ago because someone (I think it might've been James)
pointed out that, well, it isn't actually that useful. And every
subsequent call for use cases since has been answered with, "well,
the use case is that you want it to be async."
Only, that's a *server* developer's use case, not an app developer's
use case... and only for a minority of server developers, at that.
_______________________________________________
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/alex.gronholm%40nextday.fi
_______________________________________________
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/alex.gronholm%40nextday.fi
_______________________________________________
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
