[Web-SIG] WSGI 2.0
manlio_perillo at libero.it
Thu Oct 4 18:37:04 CEST 2007
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:
> """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
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
More information about the Web-SIG