Manlio Perillo wrote: > Phillip J. Eby ha scritto: >> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: >>> Phillip J. Eby ha scritto: >>>> In other words, those flags were to support legacy frameworks detecting >>>> that they were in an incompatible hosting environment. However, IIUC, >>>> there is no such existing framework that could meaningfully use the >>> flag >>>> you're proposing, that has any real chance of being portable to >>>> different WSGI environments. >>> This is true, but I continue to think that it is worth adding that flag. >>> Asynchronous support is available in Nginx mod_wsgi, and in the future >>> someone can implement a WSGI gateway for lighttpd. >> Right now, the definition of the flag is not sufficiently defined for my >> taste. You have only proposed that it be set to indicate that >> interleaved execution is possible -- but it is *always* possible to have >> interleaved execution in WSGI 1.0, so the only reason to add the flag to >> WSGI 2.0 would be so a server could promise NOT to interleave >> execution. And what good is that? >> > > Ok, here is more useful definition. > > If wsgi.asynchronous evaluates to true, then the WSGI application *will* > be executed into the server main process cycle and thus the application > execution *will* be interleaved (since this is the only way to support > multiple concurrent requests).
Isn't the more important distinction that the application must not block? Kind of like wsgi.multithread means the application must be threadsafe. Ian _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
