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.
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. ;-)
_______________________________________________
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
