Re: PEP 444 / WSGI 2 Async

Alice Bevan–McGregor <alice-h+KYGxXtFYrqlBn2x/[email protected]>
Newsgroups gmane.comp.python.web
Message-ID <[email protected]>
On 2011-01-07 08:10:43 -0800, P.J. Eby said:
> At 12:39 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote:
>> :: Image scaling would benefit from multi-processing (spreading 
>> the>load across cores). Also, only one sacle is immediately 
>> required>before returning the post-upload page: the thumbnail.  The 
>> other>scales can be executed without halting the WSGI application's 
>> return.
>> 
>> :: Asset content extraction and indexing would benefit from>threading, 
>> and would also not require pausing the WSGI application.
> 
> In all these cases, ISTM the benefit is the same if you future theWSGI 
> apps themselves (which is essentially what most current asyncWSGI 
> servers do, AFAIK).

Image scaling and asset content extraction should not block the 
response to a HTTP request; these need to be 'forked' from the main 
request.  Only template generation (where the app needs to effectively 
block pending completion) is solved easily by threading the whole 
application call.

>> :: Long-duration calls to non-async-aware libraries such as DB access.
>> The WSGI application could queue up a number of long DB queries,>pass 
>> the futures instances to the template, and the template could>then 
>> .result() (block) across them or yield them to be suspended and>resumed 
>> when the result is available.
>> 
>> :: True async is useful for WebSockets, which seem a far 
>> superior>solution to JSON/AJAX polling in addition to allowing real 
>> web-based>socket access, of course.
> 
> The point as it relates to WSGI, though, is that there are plenty 
> ofmature async APIs that offer these benefits, and some of them 
> (e.g.Eventlet and Gevent) do so while allowing blocking-style code to 
> bewritten.  That is, you just make what looks like a blocking call, 
> butthe underlying framework silently suspends your code, without 
> tyingup the thread.
> 
> Or, if you can't use a greenlet-based framework, you can use a 
> yield-based framework.  Or, if for some reason you really wanted to 
> write continuation-passing style code, you could just use the raw 
> Twisted API.

But is there really any problem with providing a unified method for 
indication a suspend point?  What the server does when it gets the 
yielded value is entirely up to the implementation of the server; if it 
(the server) wants to use greenlets, it can.  If it has other 
methedologies, it can go nuts.

> Even if you've already written a bunch of code using raw sockets and 
> want to make it asynchronous, Eventlet and Gevent actually let youload 
> a compatibility module that makes it all work, by replacing the socket 
> API with an exact duplicate that secretly suspends your code whenever a 
> socket operation would block.

I generally frown upon magic, and each of these implementations is 
completely specific.  :/

	- Alice.


_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.