On Mar 29, 2007, at 10:41 PM, Phillip J. Eby wrote: >> It's not clear if the app_iter must be used in the same thread as the >> application. Since the application is blocking, presumably *it* >> must be >> run all in one thread. This should be more explicitly documented. > > Definitely. I think that we should not require thread affinity > between the > application and the app_iter -- my feeling at this point is that > actual > yielding is an edge case with respect to most WSGI apps. The > common case > WSGI application should be just returning a list or tuple with a > single > string in it, and not doing any complex iteration. Allowing the > server > more flexibility here is probably the better choice. > > Indeed, I'm not sure we should require thread affinity across > invocations > of app_iter.next().
I recall last time this issue was considered, one of the fundamental problems is that, if the same thread isn't used for both the app and all app_iter.next invocations, sqlite cannot be used. (unless you don't call sqlite functions in the iterate part, of course). And I'm sure there's other libraries that are similarly thread-safe but only if you restrict yourself to a single thread per handle. That problem made me uncomfortable enough with using non-dedicated threads that I didn't attempt it. If WSGI 2.0 explicitly states that each call to the app's iterator can occur on a different thread, then I'd be more confident in telling people that it's their code that was broken. I suppose another flag could be added "wsgi.dedicated_thread" which is True only if every call to .next will be on the same thread as the call to your app. Of course that doesn't really help an app broken by it, just lets them error out early. James _______________________________________________ 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