You are right and now i see that Naviserver does not do this right
because our global cache keeps strings only. It looks like waste of
resource now caching file contents only but ns_share uses Tcl_Objs
internally, so it is possible to use it instead maybe?
Andrew Piskorski wrote:
On Thu, Jul 13, 2006 at 04:53:51PM -0400, Andrew Piskorski wrote:
On Thu, Jul 13, 2006 at 09:28:00PM +0100, Stephen Deasey wrote:
Except... Rob found a neat way to cheat by passing the script as an
arg to a do-nothing 'for' command. 'for' compiles the script for you.
Very smart and hellish to read...
But if that's the case, then what does any of this have to do with
per-thread caches? As you said, Naviserver is already cacheing the
string source of *.tcl pages, so what's preventing you from using the
same for/eval trick Rob used, for each interp?
(I must be missing something here...)
Oh, the snippet of file.tcl Vlad posted talked about:
bytecode, which will be associated with the Tcl_Obj we just cached
(as its internal representation).
Which maybe answers my question... I suspect that:
The Tcl interp is able to cache and re-use the bytecode for procs,
because the proc persists - its Tcl_Obj hangs around. But if you hand
the Tcl interp a script snippet (e.g., the entire contents of a *.tcl
page), yes a Tcl_Obj is created, but as soon as you're done evaluating
the script, that Tcl_Obj's reference count drops to zero and it goes
away. Thus there is no persistent Tcl_Obj around to hang the byte
code internal-rep on unless you explicitly create one. And, Rob used
a per-thread (or per-interp?) ns_cache to create that persistent
Tcl_Obj. Something like that?
Could a Tcl namespace variable of some sort also be used to provide
the persistant Tcl_Obj for the *.tcl script?
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
