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

[Timothy Farrell]

> If it's optional, what's the benefit for the app of getting it through WSGI instead of through importing some other standard module?

Performance primarily.  If you instantiate an executor at every page request, wouldn't that slow things down unnecessarily?  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...again for performance reasons.

Optional and not manditory because not every application wants or need such functionality.  Maybe this should be a server option instead of a spec option.  But since we already have the module available, it shouldn't be too much of a burden on server/gateway authors to add support for it.

> 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.


----- Original Message -----
From: "Guido van Rossum" <guido at python.org>
To: "Timothy Farrell" <tfarrell at owassobible.org>
Cc: web-sig at python.org
Sent: Friday, January 7, 2011 11:59:10 AM
Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor

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)