Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

[Gustaf N. <ne...@wu...>]

Am 10.07.13 15:01, schrieb David Osborne:
>
> On 8 July 2013 17:16, Gustaf Neumann <ne...@wu... 
> <mailto:ne...@wu...>> 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