[Web-SIG] WSGI 2.0

[Robin Bryce]

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:
>
> 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.
>
> 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 ?

Eg.,

for data in environ['wsgi.input']:
    if not data:
        if nothing_else_to_do:
            yield environ['wsgi.input'] # Wake me when there is more data
        else:
            do_domething()
            yield '' # wake me next time arround, irrespective of
whether there is data