[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

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.