Re: Server-side async API implementation sketches

08.01.2011 23:16, P.J. Eby kirjoitti:
> As a semi-proof-of-concept, I whipped these up:
>
>   http://peak.telecommunity.com/DevCenter/AsyncWSGISketch
>
> It's an expanded version of my Coroutine concept, updated with sample 
> server code for both a synchronous server and an asynchronous one.  
> The synchronous "server" is really just a decorator that wraps a WSGI2 
> async app with futures support, and handles pauses by simply waiting 
> for the future to finish.
>
> The asynchronous server is a bit more hand-wavy, in that there are 
> some bits (clearly marked) that will be server/framework dependent.  
> However, they should be straightforward for a specialist in any given 
> async framework to implement.
>
> What is *most* handwavy at the moment, however, is in the details of 
> precisely what one is allowed to "yield to".  I've written the 
> sketches dealing only with PEP 3148 futures, but sockets were also 
> proposed, and IMO there should be simple support for obtaining data 
> from wsgi.input.
>
> However, even this part is pretty easy to extrapolate: both server 
> examples just add more type-testing branches in their 
> "base_trampoline()" function, copying and modifying the existing 
> branches that deal with futures.
>
> The entire result is surprisingly compact -- each server weighed in at 
> about 40 lines, and the common Coroutine class used by both adds 
> another 60-something lines.
>
> In the limit case, it appears that any WSGI 1 server could provide an 
> (emulated) async WSGI2 implementation, simply by wrapping WSGI2 apps 
> with a finished version of the decorator in my sketch.
>
> Or, since users could do it themselves, this would mean that WSGI2 
> deployment wouldn't be dependent on all server implementers 
> immediately turning out their own WSGI2 implementations.
>
> True async API implementations would be more involved, of course -- 
> using a WSGI2 decorator on say, Twisted's WSGI1 implementation, would 
> give you no performance advantages vs. using Twisted's APIs directly.  
> But, as soon as someone wrote a Twisted-specific translation of my 
> async-server sketch, such an app would be portable.
>
> More discussion is still needed, but at this point I'm convinced the 
> concept is *technically* feasible.  (Whether there's enough need in 
> the "market" to make it worthwhile, is a separate question.)
I'm a bit unclear as to how this will work with async. How do you 
propose that an asynchronous application receives the request body?
>
> _______________________________________________
> Web-SIG mailing list
> [email protected]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: 
> http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi

_______________________________________________
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