Am 10.07.13 15:01, schrieb David Osborne:
On 8 July 2013 17:16, Gustaf Neumann <neum...@wu.ac.at
<mailto:neum...@wu.ac.at>> wrote:
The problem is not only the caches (otherwise it would have been
sufficient to exclude the ::tcl::* namespaces from the blueprint), but
also the definition of proc "clock", which redefines itself in
terms of
an ensemble. This makes it sensitive to the definition order.
So should the exclusion of ::tcl from the blueprint mean there should
be no ::tcl::clock variables defined from the previous invocations of
::tcl::clock commands in the interpreter after an ns_eval?
it means that the blueprint does never contain ::tcl::* variables
(and procs), so it will not contain e.g. ::tcl::clock::* variables.
The blueprint will be loaded into an interpreter which might or
might not have ::tcl::* variables already defined. It simply says,
that naviserver will not touch the ::tcl stuff.
In practice this means, when the interp has already
an initialized ::tcl::clock state, this clock state will survive
the update unchanged (e.g. via "ns_ictl update";
an update happens as well in PopInterp(),
when an initialized interp is provided to a thread).
As long as a naviserver app does not add itself content
into the ::tcl namespace, and expects that this content
is included in the blueprint, excluding is fine.
I would argue, that a naviserver app should not modify
the ::tcl namespace, therefore the change is fine.
-gustaf neumann
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
