[Web-SIG] WSGI 2.0
manlio_perillo at libero.it
Fri Oct 5 19:38:00 CEST 2007
Phillip J. Eby ha scritto:
> At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>> >> Phillip J. Eby ha scritto:
>> >> > In other words, those flags were to support legacy frameworks
>> >> > that they were in an incompatible hosting environment. However,
>> >> > there is no such existing framework that could meaningfully use the
>> >> flag
>> >> > you're proposing, that has any real chance of being portable to
>> >> > different WSGI environments.
>> >> This is true, but I continue to think that it is worth adding that
>> >> Asynchronous support is available in Nginx mod_wsgi, and in the future
>> >> someone can implement a WSGI gateway for lighttpd.
>> > Right now, the definition of the flag is not sufficiently defined
>> for my
>> > taste. You have only proposed that it be set to indicate that
>> > interleaved execution is possible -- but it is *always* possible to
>> > interleaved execution in WSGI 1.0, so the only reason to add the
>> flag to
>> > WSGI 2.0 would be so a server could promise NOT to interleave
>> > execution. And what good is that?
>> Ok, here is more useful definition.
>> If wsgi.asynchronous evaluates to true, then the WSGI application *will*
>> be executed into the server main process cycle and thus the application
>> execution *will* be interleaved (since this is the only way to support
>> multiple concurrent requests).
> I still don't see how this is *useful*. What will the application *do*
> with this information?
As an example (not tested) SQLAlchemy can implements a
RequestSingletonPool, that is the equivalend of ThreadSingetonPool.
In this case the pool will checkout a connection using the
environ['wsgi.request_id'] identifier (unique for each request), instead
So, a WSGI application *needs* to know if the application is
multithreaded or asynchronous to select the right connection pool.
Regards Manlio Perillo
More information about the Web-SIG