[Web-SIG] WSGI 2.0

[Graham Dumpleton]

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. 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.

Graham