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

[Alice Bevan–McGregor]

On 2011-01-08 17:22:44 -0800, Alex Grönholm said:

>> On 2011-01-08 13:16:52 -0800, P.J. Eby said:
>> 
>> I've written the sketches dealing only with PEP 3148 futures, but 
>> sockets were also proposed, and IMO there should be simple support for 
>> obtaining data from wsgi.input.
> 
> I'm a bit unclear as to how this will work with async. How do you 
> propose that an asynchronous application receives the request body?

In my example https://gist.github.com/770743 (which has been simplified 
greatly by P.J. Eby in the "Future- and Generator-Based Async Idea" 
thread) for dealing with wsgi.input, I have:

    future = environ['wsgi.executor'].submit(environ['wsgi.input'].read, 4096)
    yield future

While ugly, if you were doing this, you'd likely:

	submit = environ['wsgi.executor'].submit
	input_ = environ['wsgi.input']

    future = yield submit(input_.read, 4096)
    data = future.

That's a bit nicer to read, and simplifies things if you need to make a 
number of async calls.

The idea here is that:

:: Your async server subclasses ThreadPoolExecutor.

:: The subclass overloads the submit method.

:: Your submit method detects bound methods on wsgi.input, sockets, and files.

:: If one of the above is detected, create a mock future that defines 
'fd' and 'operation' attributes or similar.

:: When yielding the mock future, your async reactor can detect 'fd' 
and do the appropriate thing for your async framework.  (Generally 
adding the fd to the appropriate select/epoll/kqueue readers/writers 
lists.)

:: When the condition is met, set_running_or_notify_cancel (when 
internally reading or writing data), set_result, saving the value, and 
return the future (filled with its data) back up to the application.

:: The application accepts the future instance as the return value of 
yield, and calls result across it to get the data.  (Obviously writes, 
if allowed, won't have data, but reads will.)

I hope that clearly identifies my idea on the subject.  Since async 
servers will /already/ be implementing their own executors, I don't see 
this as too crazy.

	- Alice.