Phillip J. Eby ha scritto: > [...] >> and existing >> WSGI implementations does not interleave the iteration, as far as I know. > > Nothing in the spec stops them from doing so - indeed, they're > *encouraged* to do so: > > http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-boundaries > > > > """This requirement ensures that asynchronous applications and servers > can conspire to reduce the number of threads that are required to run a > given number of application instances simultaneously.""" > > Notice that the only way this sentence works is if you are interleaving > applications. >
What "normal" HTTP servers do is to "pause" the iteration, until the entire buffer has been sent to the client. They can do this, since they run in a dedicated thread or process. With nginx this is not true. nginx mod_wsgi will pause the iteration associated with a given request, but will start a new iteration as soon as a new request arrives, and this in the *same* thread. 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. With nginx mod_wsgi this is not true, when a WSGI application set the counter value to, say, 6, and a new request arrives, the application associated with the previous request will now see the value 0, not 6, when it will be unpaused. > That being said, the PEP really needs an explicit discussion of the > execution model. 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
