[Web-SIG] WSGI 2.0

[Manlio Perillo]

Graham Dumpleton ha scritto:
> On 07/10/2007, Manlio Perillo <manlio_perillo at libero.it> 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.
>>
>> Of course, a WSGI application can use threads, but i think that it
>> *needs* a wsgi.pause_output extension, for synchronization.
> 
> I appreciate that you can't use the thread support in nginx, but what
> I don't understand is why you can't utililise Python threading API (or
> even POSIX threads) at the boundary between nginx and the interface
> into the WSGI application, ie., in the WSGI adapter layer, so as to
> emulate a synchronous style WSGI interface on top of the nginx event
> driven layer. 

This is possible, but I think that it is better to offer a basic 
asynchronous support in WSGI, since in this way it is possible to build 
threading support in pure Python *and*, more important, this support is 
reusable by other implementations.

> In other words you hide all the complexity of any queues
> or other synchronisation mechanisms for communicating any data between
> the two within the adapter. This way you do not need to expose an
> asynchronous API to the WSGI application itself and existing WSGI code
> can be used as is.
> 

The Python threading support can be implemented as a "middleware", so it 
is trasparent to the WSGI application.

Not sure if it can be called "middleware", however.



Regards  Manlio Perillo