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

[P.J. Eby]

At 04:40 AM 1/9/2011 +0200, Alex Grönholm wrote:
>09.01.2011 04:15, Alice Bevan­McGregor kirjoitti:
>>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.
>-1 on this. Those executors are meant for executing code in a thread 
>pool. Mandating a magical socket operation filter here would 
>considerably complicate server implementation.

Actually, the *reverse* is true.  If you do it the way Alice 
proposes, my sketches don't get any more complex, because the 
filtering goes in the executor facade or submit function.

Truthfully, I don't really see the point of exposing the map() method 
(which is the only other executor method we'd expose), so it probably 
makes more sense to just offer a 'wsgi.submit' key...  which can be a 
function as follows:

       def submit(callable, *args, **kw):
           ob = getattr(callable, '__self__', None)
           if isinstance(ob, ServerProvidedSocket):  # could be an ABC
                future = MockFuture()
                if callable==ob.read:
                    # set up read callback to fire future
                elif callable==ob.write:
                    # set up write callback to fire future
                return future
           else:
               return real_executor.submit(callable, *args, **kw)

Granted, this might be a rather long function.  However, since it's 
essentially an optimization, a given server can decide how many 
functions can be shortcut in this way.  The spec may wish to offer a 
guarantee or recommendation for specific methods of certain 
stdlib-provided types (sockets in particular) and wsgi.input.

Personally, I do think it might be *better* to offer extended 
operations on wsgi.input that could be used via yield, e.g. "yield 
input.nb_read()".  But of course then the trampoline code has to 
recognize those values instead of futures.  Either way works, but 
somewhere there is going to be some type-testing (explicit or 
implicit) taking place to determine how to suspend and resume the app.

Note, too, that this complexity also only affects servers that want 
to offer a truly async API.  A synchronous server has no reason to 
pay particular attention to what's in a future, since it can't offer 
any performance improvement.

I do think that this sort of API discussion, though, is the most 
dangerous part of trying to do an async spec.  That is, I don't 
expect that everyone will spontaneously agree on the exact same 
API.  Alice's proposal (simply submitting object methods) has the 
advantage of severely limiting the scope of API discussions.  ;-)