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

[Alice Bevan–McGregor]

On 2011-01-07 09:47:12 -0800, Timothy Farrell said:

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

Done.  (In terms of implementation, not updating PEP 444.)  :3

The Marrow server now implements a thread pool executor using the 
concurrent.futures module (or equiv. futures PyPi package).  The 
following are the commits; the changes will look bigger than they are 
due to cutting and pasting of several previously nested blocks of code 
into separate functions for use as callbacks.  100% unit test coverage 
is maintained (without errors), an example application is added, and 
the benchmark suite updated to support the definition of thread count.

	http://bit.ly/gUL33v
	http://bit.ly/gyVlgQ

Testing this yourself requires Git checkouts of the 
marrow.server/threading branch and marrow.server.http/threading branch, 
and likely the latest marrow.io from Git as well:

	https://github.com/pulp/marrow.io
	https://github.com/pulp/marrow.server/tree/threaded
	https://github.com/pulp/marrow.server.http/tree/threaded

This update has not been tested under Python 3.x yet; I'll do that 
shortly and push any fixes; I doubt there will be any.

On 2011-01-08 03:26:28 -0800, Alice Bevan–McGregor said in the [PEP 
444] Future- and Generator-Based Async Idea thread:

> As a side note, I'll be adding threading support to the server... but I 
> suspect the overhead will outweigh the benefit for speedy applications.

I was surprisingly quite wrong in this prediction.  The following is 
the output of a C25 pair of benchmarks, the first not threaded, the 
other with 30 threads  (enough so there would be no waiting).

	https://gist.github.com/770893

The difference is the loss of 60 RSecs out of 3280.  Note that the 
implementation I've devised can pass the concurrent.futures executor to 
the WSGI application (and, in fact, does), fufilling the requirements 
of this discussion.  :D

The use of callbacks internally to the HTTP protocol makes a huge 
difference in overhead, I guess.

	- Alice.