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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
