Understood. I realize it is much further out, but since we are on topic, if TG 2.5 or later were to adopt pyramid (which preserves tmpl_context only as a backward compat), I suppose TG will provide an equivalent of the current tmpl_context.
On Tuesday, September 4, 2012 11:51:17 AM UTC-7, Alessandro Molina wrote: > > Sorry, I was not saying that it changed during the last release, so > currently there isn't any changelog you can look at for informations > about that. > > More generally speaking controller instances should be considered an > internal implementation detail and how they are stored and reused can > vary any time for performance reasons, while tg.tmpl_context and > tg.request are actually meant for storing request related variables > and will always behave properly for that use case. > > That is the reason why I'm suggesting you to avoid storing request > related variables inside the controller, unless you created the > controller yourself during the request life cycle (for example inside > a _lookup) as in that case the controller instance relies only to the > thread the is handling the request for sure. > > On Tue, Sep 4, 2012 at 6:40 PM, ozwyzard <[email protected] <javascript:>> > wrote: > > Thank you. Is there some document that would talk a few points on > context, > > threads, (locking issues if any), etc. Or does one have to read the > > dispatcher code? Sometimes documents are a context-switch for the > brain. > > If there are any detailed notes in the code or README_DESIGN.txt in a > > separate file, let me know. I have the pylons book, but do not > recollect it > > going into such detail. Thanks again. Congratulations on TG 2.2! > > > > On Tuesday, September 4, 2012 1:13:02 AM UTC-7, Alessandro Molina wrote: > >> > >> On Tue, Sep 4, 2012 at 4:28 AM, ozwyzard <[email protected]> wrote: > >> > Thanks for confirming that it would lead to race conditions. Agree > that > >> > one > >> > can store request context variables in request or tmpl_context. > Thank > >> > you! > >> > > >> > >> It actually depends on the TG version as some reuse the controller > >> instance for multiple requests, > >> for that reason relying on the ability of storing controller > >> properties is not suggested. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "TurboGears" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/turbogears/-/Ca3e1UkprxsJ. > > > > To post to this group, send email to > > [email protected]<javascript:>. > > > To unsubscribe from this group, send email to > > [email protected] <javascript:>. > > For more options, visit this group at > > http://groups.google.com/group/turbogears?hl=en. > -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To view this discussion on the web visit https://groups.google.com/d/msg/turbogears/-/wmfISGylA1YJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
