At 11:08 PM 3/29/2007 -0400, 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.
Right -- but the point here is that you only need to *have* an iterator if you're doing server push or trying to stream large files. I don't mind making these corner cases a bit tougher to implement, since they're fairly tough already. If you're running a WSGI 1.0 app under a 2.0->1.0 adapter, you can always use an adapter that ensures thread affinity. Indeed, any 2.0->1.0 adapter that supports multiple write() calls is going to need to have some sort of threading mechanism anyway, unless it uses greenlets. >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. I'd like to have fewer optional things, rather than more, so I think we should either require a dedicated thread or make it non-dedicated. It should be quite straightforward to implement a middleware component that ensures its wrappee is run entirely within a dedicated thread, using a Queue. _______________________________________________ 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