Phillip J. Eby ha scritto: > At 05:14 PM 10/5/2007 +0200, 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). > > I still don't see how this is *useful*. What will the application *do* > with this information? >
As an example (not tested) SQLAlchemy can implements a RequestSingletonPool, that is the equivalend of ThreadSingetonPool. In this case the pool will checkout a connection using the environ['wsgi.request_id'] identifier (unique for each request), instead of thread.get_ident. So, a WSGI application *needs* to know if the application is multithreaded or asynchronous to select the right connection pool. Regards Manlio Perillo _______________________________________________ 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