Hi!
After spenging a weekend over this, I know less than
before...
The question is how we are going to improve the Tcl
initialization so people could benefit from that better
than now?
As of today, what we have is:
a.
introspective script based on the "old" way as 4.0 AS
did it (init the interp by loading all Tcl files then
run a script to pull-out namespaces, variables etc and
create a script that get saved with [ns_ictl save]
and run in each new interp by [ns_ictl update])
b.
the ttrace way of setting Tcl traces on selected commands
and have the "things" setup by those commands record in
shared nsv arrays. Then use Tcl [unknown] to pull out the
"things" on as-needed basis from shared arrays
Well, none of those is really good. The a. is limited in
what it "introspects". The b. is pretty complex and in some
situations it does not work as expected (although there is
no design problem there, more probably just a bug or lack a
feature).
Now, we do have [ns_ictl trace] where one can register things
to execute at interp creation, allocation etc.
So, I tried to do a simple thing: for each script executed
during the startup of the server I create
[ns_ictl trace [list source $file]]
create-trace.
This "mostly" works, but has two negative effects:
1. all scripts needs to be re-adjusted as they are going to
be sourced more than once (for each new interp)
2. in case 1000's of files are needed for the startup this may
pose significant delay in interp creation
I think that old AS approach is the worst as it is really limited.
The Tcl-trace based approach is better but is known to have some
problems (I do not know which ones), yet, it is pretty powerful
and has some other nice side-effects (less memory footprint).
Lastly, the [ns_ictl trace] is simplest to understand and deploy
(this is also very important) but requires rewriting of existing
scripts and most probably needs somekind of caching to speedup
the load process when 1000's of startup files are involved.
For me, the Tcl-trace or ns_ictl trace are the way to go.
Looking at those two, the latter is more appealing since of the
simplicity, but it may hit us hard speedwise. OTOH, the former
is faster and uses far less resources but is pretty complex in
implementation (this might be done simpler, yes, yet it is always
going to be more complex than ns_ictl trace).
Now, what you all think? Should we do something there or should
we just stay with the old AS introspective script?
Cheers
Zoran
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
