[Web-SIG] Server-side async API implementation sketches

[Alice Bevan–McGregor]

On 2011-01-09 07:04:49 -0800, 
exarkun at twistedmatrix.com said:
> I think this effort would benefit from more thought on how exactly 
> accessing this external library support will work.  If async wsgi is 
> limited to performing a single read asynchronously, then it hardly 
> seems compelling.

Apologies if the last e-mail was too harsh; I'm about to go to bed, and 
it' been a long night/morning.  ;)

Here's a proposed solution: a generator API on top of futures.

If the async server implementing the executor can detect a generator 
being submitted, then:

:: The executor accepts the generator and begins iteration (passing the 
executor and the arguments supplied to submit).

:: The generator is expected to be /fast/.

:: The generator does work until it needs an operation over a file 
descriptor, at which point it yields the fd and the operation (say, 
'r', or 'w').

:: The executor schedules with the async reactor the generator to be 
re-called when the operation is possible.

:: The Future is considered complete when the generator raises 
GeneratorExit and the first argument is used as the return value of the 
Future.

Yielding a 2-tuple of readers/writers would work, too, and allow for 
more concurrent utilization of sockets, though I'm not sure of the use 
cases for this.  If so, the generator would be woken up when any of the 
readers or writers are available and sent() a 2-tuple of 
available_readers, available_writers.

The executor is passed along for any operations the generator can not 
accomplish safely without threads, and the executor, as it's running 
through the generator, will accomplish the same semantics as iterating 
the WSGI application: if a future instance is yielded, the generator is 
suspended until the future is complete, allowing heavy processing to be 
mixed with async calls in a fully async server.

The wsgi.input operations can be implemented this way, as can database 
operations and pretty much anything that uses sockets, pipes, or 
on-disk files.  In fact, the WSGI application -itself- could be called 
in this way (with the omission of the executor or a simple wrapper that 
saves the executor into the environ).

Just a quick thought before running off to bed.

	- Alice.