Re: Server-side async API implementation sketches
exarkun-wgPraSjSqjuEakHPNWoOSQC/[email protected]
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <20110109150449.1889.786099218.divmod.xquotient.27@localhost.localdomain> |
On 11:36 am, alice-h+KYGxXtFYrqlBn2x/[email protected] 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 BevanMcGregor 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 _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org