On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell 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.
+1
On 2011-01-07 11:07:36 -0800, Timothy Farrell said:
On 2011-01-07 09:59:10 -0800, Guido van Rossum said:
If it's optional, what's the benefit for the app of getting it through
WSGI instead of through importing some other standard module?
Aside from that, servers currently specify if they are multi-threaded
and/or multi-process. Having the server provide the executor allows it
to provide an executor that most matches its own concurrency model...
I think that's the bigger point; WSGI servers do implement their own
concurrency model for request processing and utilizing a
server-provided executor which interfaces with whatever the internal
representation of concurrency is would be highly beneficial. (Vs. an
application utilizing a more generic executor implementation that adds
a second thread pool...)
Taking futures to be separate and distinct from the rest of async
discussion, I still think it's an extremely useful feature. I outlined
my own personal use cases in my slew of e-mails last night, and many of
them are also not time sensitive. (E.g. image scaling, full text
indexing, etc.)
Maybe this should be a server option instead of a spec option.
It would definitely fall under the Server API spec, not the application
one. Being optional, and with simple (wsgi.executor) access via the
environ would also allow middleware developers to create executor
implementations (or just reference the concurrent.futures
implementation).
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.
I'm not following you here. What's wrong with executor.submit() that
might need changing? Granted, it would not be ideal if an application
called executor.shutdown(). This doesn't seem difficult to my tiny
brain.
The "perfect" executor API is already well defined in PEP 3148 AFIK.
Specific methods with specific semantics implemented in a duck-typed
way. The underlying implementation is up to the server, or the server
can utilize an external (or built-in in 3.2) futures implementation.
If WSGI 2 were to incorporate futures as a feature there would have to
be some mandate as to which methods applications and middleware are
allowed to call; similar to how we do not allow .close() across
wsgi.input or wsgi.errors.
- Alice.
_______________________________________________
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
