[Web-SIG] WSGI 2.0

Graham Dumpleton graham.dumpleton at gmail.com
Fri Oct 5 02:41:09 CEST 2007


On 05/10/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
> >Phillip J. Eby ha scritto:
> > > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote:
> > >> But why you are against adding a new environ value (not necessary named
> > >> wsgi.asynchronous), that will explicitly state if the WSGI server will
> > >> interleave the WSGI application?
> > >
> > > Why do you think it's useful?
> >
> >For the same reason you think wsgi.multiprocess is useful.
>
> Actually, I don't think it's all that useful; IIRC, it was added as a
> compromise to the spec, to fend off a proposal for a more complex
> server-capabilities API.  :)
>
> Also, there's an important difference between your proposed addition
> and the multiprocess/multithread flags, which is that there existed
> frameworks that could be ported to WSGI that only supported one model
> or the other.  I.e., frameworks that could only run multi-threaded,
> or only multi-process.

FWIW, one example where the flags are useful is in WSGI components
such as browser based debuggers such as EvalException as they could
disable themselves or flag an error when used in a multiprocess web
server where there would be no guarantee that a subsequent request
would end up back at the same process.

Graham


More information about the Web-SIG mailing list