[Web-SIG] WSGI 2.0

[Ian Bicking]

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 detecting
>>>> that they were in an incompatible hosting environment.  However, IIUC,
>>>> 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 flag.
>>> 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 have 
>> 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).

Isn't the more important distinction that the application must not 
block?  Kind of like wsgi.multithread means the application must be 
threadsafe.

   Ian