[Web-SIG] WSGI 2.0

Manlio Perillo manlio_perillo at libero.it
Mon Oct 8 13:02:27 CEST 2007


Ian Bicking ha scritto:
> Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote:
>>>> As an example, the WSGI write callable cannot be implemented in a
>>>> conforming way in Nginx.
>>> ...unless you use a separate thread or process.
>>>
>>
>> I'm insisting about asynchronous support in WSGI because
>> Nginx *does not supports threads*.
>>
>> It has some thread support but it is *broken*.
>> Even if in future the problems are solved, the threading model of 
>> Nginx *will break* many existing WSGI applications, since the WSGI 
>> iteration can be resumed in different threads.
> 
> Just so you are aware -- almost all current WSGI applications block, and 
> can't be run in asynchronous environments.  

Not every WSGI application "blocks" the request processing for a 
"sensible" amount of time.

A streaming application, as an example, can "block" without problems, 
since nginx mod_wsgi will pause the execution as soon as the application 
output cannot be written at once to the client.

Moreover, as I have already written, using the wsgi.pause_output, it 
should possible to write a WSGI "component" that run the entire WSGI 
application in a separate thread (but, in this case, it MUST buffer the 
entire output, since nginx is not thread safe).

Nginx can also use several worker processes, so it can still (somehow) 
serve "blocking" applications.

> So if you are writing WSGI 
> support that doesn't support applications that block, well, it won't 
> really be able to do much with current WSGI code.
> 

Supporting "legacy" and "huge" WSGI applications is not really a 
priority for me.

I want some support for adding extensions that can be used by other WSGI 
implementations that want to support asynchronous applications in 
asynchronous server.

I can add "proprietary" extensions, but Python is already full of not 
interoperable web solutions.



P.S.
Since, as I can see, many people on this mailing list are not interested 
in asynchronous support for WSGI, we can stop this thread (and further 
discussions) here.





Regards  Manlio Perillo


More information about the Web-SIG mailing list