At 01:53 PM 2/1/2006 -0500, Chris McDonough wrote: >One specific concern about the "returning the published object" for >publisher-based frameworks is that often the published object has >references to other objects that might not make sense in the context >of the thread handling the rendering of the template. For example, >if you're using a thread pool behind a Twisted server, and the thing >doing the rendering is in "the main thread", methods hanging off of >the "published object" might try to make use of thread-local storage, >which would fail. Zope 3 uses thread-local storage for request >objects, IIRC. > >This might be a nonissue, because I'm a little fuzzy on which >component(s) actually do(es) the rendering of the template in the >models being proposed. But the amount of fuzziness I have about >what's trying to be specified here makes me wonder if there aren't >better things to go specify.
At least WSGI already has something approaching a defined threading model. :) Granted, recent discussion has shown that it's lacking in a few areas, but we could kill two birds with one stone here by fixing those bits. I would also note, however, that your comments actually suggest that the use of thread-locals for context is in fact a bad thing, and in fact I have written something better that allows contexts to be handed off to other threads or used in massively parallel pseudothreads. I.e., they are "context locals" rather than "thread locals", and you can instantaneously switch an unbounded number of them in or out in an O(1) operation, without even having to know which ones may be in use. You simply get *all* of them, so it's quite scalable. If you needed to hand off tasks between threads, you could hand off their complete execution context that way. Of course, this is off-topic for Web-SIG, so anyone can email me privately if they're curious. However, if the library ever does find its way into the stdlib, then it might be reasonable to reference it in later WSGI versions. (E.g. as "if you run iterations of the same app return value from multiple threads, a server MUST save and restore the active context locals across thread switches".) I think this would actually fix most of the thread-related issues that have popped up in recent discussion. _______________________________________________ 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
