[Web-SIG] WSGI 2.0
manlio_perillo at libero.it
Fri Oct 5 17:34:05 CEST 2007
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
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)
Regards Manlio Perillo
More information about the Web-SIG