[Web-SIG] WSGI 2.0

[Manlio Perillo]

Ian Bicking ha scritto:
> [...]
>> 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.
> 

Right, but I assume that this is evident when I say "executed into the 
server main process cycle".

An interesting example is an application that will read some data from a 
source (as an example from a video capture device) and will send the 
output to the web.

The application can blocks when reading, but as soon as it will yield 
some data, the server can interleave calls to it.

This means that the WSGI application can not use a "global" handle to 
the video capture device, or use thread specific data.

It must be able to store the device handle on a per request "context".

This is the reason why I'm writing a spec for a `wsgi.context_id` 
extension, that will return a request specific identifier (in the same 
way as it is done by os.getpid or thread.get_ident)


>   Ian
> 


Regards  Manlio Perillo