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

[Alice Bevan–McGregor]

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.