[Web-SIG] Standardized template API

[Phillip J. Eby]

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.