Phillip J. Eby ha scritto: > At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote: >> To make an example (not tested), suppose that a WSGI application keeps a >> global counter (as a thread specific data). >> >> When a new request arrives, the counter is reset to 0, and its value is >> incremented for every iteration. >> >> With all the existing WSGI implementation (as far as I know), we always >> know the current value of the counter: it will start at 0, reach the >> number of iterations, and then will start at 0 again. > > So? An application that does this is obviously broken. Again, remember > that the WSGI spec encourages interleaving, so any multi-threaded server > is well within its rights to do the same thing. > > There is nothing in WSGI that says multiple simultaneous requests cannot > be run in the same thread. Therefore, nothing is guaranteed about what > happens to global or thread-local resources while the application (or > its returned iterable) is not actually executing.
Ok. But why you are against adding a new environ value (not necessary named wsgi.asynchronous), that will explicitly state if the WSGI server will interleave the WSGI application? 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
