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

[Alex Grönholm]

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