On 11:36 am, al...@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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
