[Web-SIG] PEP 444 feature request - Futures executor

[Guido van Rossum]

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.

On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell
<tfarrell at 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 at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)