07.01.2011 19:59, Guido van Rossum kirjoitti:
If it's optional, what's the benefit for the app of getting it through
WSGI instead of through importing some other standard module? The API
of the executor will require a lot of thought. I worry that this
weighs down the WSGI standard with the responsibility of coming up
with the perfect executor API, and if it's not quite perfect after
all, servers are additionally required to support the standard but
suboptimal API effectively forever. Or they can choose not to provide
it, in which case it was a waste of time putting it in WSGI.
The only plausible reason for having a wsgi.executor object is to make
writing (asynchronous) middleware easier. Otherwise the app could just
create its own executor (as it is done now).
If there is no wsgi.executor, how will the middleware get ahold of a
thread/process pool? Having individual middleware maintain their own
pools is pretty pointless, as I'm sure everyone will agree. On the other
hand, I believe allowing wsgi.executor to be either a process pool or a
thread pool is a recipe for disaster. I'm really not sure where to go
from here.
On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell
<tfarr...@owassobible.org> wrote:
There has been much discussion about how to handle async in PEP 444 and that
discussion centers around the use of futures. However, I'm requesting that
servers _optionally_ provide environ['wsgi.executor'] as a futures executor
that applications can use for the purpose of doing something after the response
is fully sent to the client. This is feature request is designed to be
concurrency methodology agnostic.
Some example use cases are:
- send an email that might block on a slow email server (Alice, I read what you
said about Turbomail, but one product is not the solution to all situations)
- initiate a database vacuum
- clean a cache
- build a cache
- compile statistics
When serving pages of an application, these are all things that could be done
after the response has been sent. Ideally these things don't need to be done
in a request thread and aren't incredibly time-sensitive. It seems to me that
futures would be an ideal way of handling this.
Thoughts?
_______________________________________________
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/guido%40python.org
_______________________________________________
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
