James Y Knight wrote: > > 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.
This aspect of SQLite totally sucks. But I haven't encountered any other libraries with the same restrictions. I might just not notice -- quite possible -- but still, I haven't noticed it. And of course pre-fetching the results solves the problem. The advantages seem much more substantial than to make it worth it to cater to one stupid library. At least it *seems* like there's an advantage, in that an async server could handle lots of slow-consuming clients (or large responses) without a whole lot of overhead, because it could deal with all the app_iter's in a single thread. If that wouldn't work anyway, then it's no good, but I'm assuming that could work. > 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. That's essentially what wsgi.threaded and wsgi.multiprocess do. I think it's a reasonable thing to give, because there is some potential that you'd get incorrect data instead of an exception if there really was problematic code. And it would allow a SQLite user to at least call list() (or fetchall) on their app_iter. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers _______________________________________________ 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
