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

[exarkun at twistedmatrix.com]

On 11:36 am, alice at gothcandy.com wrote:
>On 2011-01-08 19:34:41 -0800, P.J. Eby said:
>>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.
>
>Indeed; the executor is what then adds the file descriptor to the 
>underlying server async reactor (select/epoll/kqueue/other).  In the 
>case of the Marrow server, this would utilize a reactor callback (some 
>might say "deferred") to

Don't say it if it's not true.  Deferreds aren't tied to a reactor, and 
Marrow doesn't appear to have anything called "deferred".  So this 
parallel to Twisted's Deferred is misleading and confusing.
>
>Since each async server will either implement or utilize a specific 
>async framework, each will offer its own "async-supported" featureset. 
>What I mean is that all servers should make wsgi.input calls async- 
>able, some would go further to make all socket calls async.  Some might 
>go even further than that and define an API for external libraries 
>(e.g. DBs) to be truly cooperatively async.

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.

Jean-Paul