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

[P.J. Eby]

At 06:15 PM 1/8/2011 -0800, Alice Bevan­McGregor wrote:
>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.

I don't quite understand the above -- in my sketch, the above would be:

     data = yield submit(input._read, 4096)

It looks like your original sketch wants to call .result() on the 
future, whereas in my version, the return value of yielding a future 
is the result (or an error is thrown if the result was an error).

Is there some reason I'm missing, for why you'd want to explicitly 
fetch the result in a separate step?

Meanwhile, thinking about Alex's question, ISTM that if WSGI 2 is 
asynchronous, then the wsgi.input object should probably just have 
read(), readline() etc. methods that simply return (possibly-mock) 
futures.  That's *much* better than having to do all that submit() 
crud just to read data from wsgi.input().

OTOH, if you want to use the cgi module to parse a form POST from the 
input, you're going to need to write an async version of it in that 
case, or else feed the entire operation to an executor...  but then 
the methods would need to be synchronous...  *argh*.

I'm starting to not like this idea at all.  Alex has actually 
pinpointed a very weak spot in the scheme, which is that if 
wsgi.input is synchronous, you destroy the asynchrony, but if it's 
asynchronous, you can't use it with any normal code that operates on a stream.

I don't see any immediate fixes for this problem, so I'll let it 
marinate in the back of my mind for a while.  This might be the 
achilles heel for the whole idea of a low-rent async WSGI.