[Web-SIG] WSGI 2.0

[Manlio Perillo]

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