[Web-SIG] WSGI 2.0
robinbryce at gmail.com
Fri Oct 5 18:34:23 CEST 2007
On 04/10/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:54 PM 10/4/2007 +0200, Manlio Perillo wrote:
> >Phillip J. Eby ha scritto:
> > > At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote:
> > >> Phillip J. Eby ha scritto:
> > >> > It's always the case that a WSGI application can be paused after it
> > >> > yields data, even in WSGI 1.0.
> > >>
> > >> I was not aware of this.
> > >> It may cause some problems to a unaware WSGI application the fact that a
> > >> new "handler" is started "interleaved" with the previous ones.
> > >
> > > It may... but the only applications that should be yielding anything are
> > > ones that are sending large files, doing server push, or explicitly
> > > *desire* to be interleaved in such fashion.
> > >
> >But they have no way to know if the server supports this,
> If it's a WSGI-compliant server, it supports this by
> definition. It's just that synchronous servers don't pause before
> requesting the next iteration.
> > 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 applications.
> That being said, the PEP really needs an explicit discussion of the
> execution model.
Is there a means to support a non blocking read on wsgi.input ?
for data in environ['wsgi.input']:
if not data:
yield environ['wsgi.input'] # Wake me when there is more data
yield '' # wake me next time arround, irrespective of
whether there is data
More information about the Web-SIG