WSGI support (was [Twisted-web] Re: status of Twisted Web and Web 2)

[Manlio Perillo]

David Reid ha scritto:
> 
> On Mar 6, 2008, at 2:00 AM, Manlio Perillo wrote:
>> Maybe it can be of interest my work on adding asynchronous support in 
>> WSGI.
>>
>> I'm developing a WSGI module for the Nginx web server:
>> http://hg.mperillo.ath.cx/nginx/mod_wsgi/
>>
>> The great advantage of Nginx over Twisted is it's support for multiple 
>> worker processes; this helps a lot with application "reloading" and 
>> for better support of I/O bound applications.
> 
> I'm not quite convinced that the concurrency model of the container is 
> the real bottleneck in WSGI applications as opposed to it's synchronous 
> API.
> A Twisted WSGI container could use a process pool just as easily as a 
> thread pool, but you're still taking a properly asynchronous container 
> and letting it run an application that will block for a long period of 
> time.
> 


I'm speaking about the support to asynchronous WSGI applications.

I now that most of the current applications are synchronous, but I'm 
speaking about asynchronous application and the best way to support them 
with WSGI.

>> I think that having a "pure" asynchronous WSGI implementation in 
>> Twisted Web that implements this extension can be a good starting 
>> point for trying to standardize asynchronous web applications.
>>
>>
>> P.S.: the wsgi.pause_output extension, proposed some years ago here by 
>> Donovan Preston should be very easy to implement using ngx.poll, and a 
>> pipe.
> 
> Does anyone support said extension?  

No, I just invented it 2 days ago :).

> Does everyone support the same 
> pause_output? 

No.

> Or just functions of the same name?
> 

?

> It shouldn't be very hard to add support for it to Twisted.web2's WSGI 
> implementation either, 

No, it's not easy.

In Twisted Web2 WSGI implementation the application runs in a separate 
thread.
The poll extension requires the registration of a file descriptor in the 
reactor, but this must be done in the main thread, since Twisted is not 
thread safe.

> but I don't much see the point if no one else 
> supports it.  

Well, if Twisted implements it, then we have two interoperable 
implementations.

There are not so many asynchronous web servers.

> I'm not convinced that WSGI is at all a useful means of 
> writing asynchronous web applications.  

I don't think so.
Instead, it is possible to write asynchronous applications using a very 
convenient API.

> I think WSGI's only benefit is 
> that it allows you to almost write your application code once and run it 
> on multiple containers.
> 

Right, and I would like the same to be possible with asynchronous 
applications.

I, by default, will use Nginx but I want to have the possibility to 
switch to Twisted when I need to use some of the protocols already 
implemented in it.

> -David
> 


Manlio Perillo