In a message dated 4/30/2001 8:58:36 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
> On 2001.04.30, Jim Davidson <[EMAIL PROTECTED]> wrote:
> [ ... ns_stats, command traces, nsd/tclstats.c, etc. ... ]
> >
> > I removed this from 4.x because it was being used much and requred an
> > undocumented, non-virtual server safe API no longer available.
>
> Of course you had to burst my bubble, didn't you? ;-)
>
> Did you remove it because it couldn't be fixed up in the current
> state of AOLserver, or because you just didn't have time to fix it
> up?
>
> In other words, is it worthwhile for me to go and reimplement this
> for 4.x? As I mentioned, I'd prefer to do it as a separately loadable
> module like "nsprofiler" or "nsstats" (perhaps the latter is more
> catchy) ... so that people could load the module, which could then
> be toggled on or off at runtime.
>
> I'm curious specifically which API you're referring to, as well.
>
> Also, do you have any rough draft documentation regarding the
> new virtual-server API? Is it both hardware and software virtual
> server (both IP and name-based)? Do I just have to look through
> the cvs logs to see what files you've been touching? ;-)
>
Hi,
If you look at the old nsd/tclstats.c code, you'll find this:
void
NsTclStatsInit(void)
{
Tcl_InitHashTable(&statsTable, TCL_STRING_KEYS);
Ns_MutexSetName2(&lock, "ns", "tclstats");
if (nsconf.tcl.statlevel > 0) {
Ns_Log(Warning, "tclstats: tracing to level %d",
nsconf.tcl.statlevel);
Ns_TclRegisterAtCreate(CreateTrace, NULL);
if (nsconf.tcl.statmaxbuf > 0) {
Ns_TlsAlloc(&tls, FreeBuf);
Ns_TclRegisterAtCleanup(FlushBufTrace, NULL);
}
}
}
Neither the "Ns_TclRegisterAtCreate" nor the "Ns_TclRegisterAtCleanup" API's
exist in AOLserver 4.x.
Ns_TclRegisterAtCleanup was removed because it's not virtual-server safe
(i.e., it doesn't take the "server" as a first argument) and because cleanup
is now generally handled via new command options in the ns_cleanup proc
(e.g., "ns_db cleanup") so folks can fiddle with the cleanup behavior as they
wish.
Ns_TclRegisterAtCreate was removed because the new semantics of
Ns_TclInitInterps no longer require such a callback. This is a more subtle
change from 3.x which was also different in 2.x. Consider the following code
which is common in AOLserver modules:
static int
AddCmds(Tcl_Interp *interp, void *arg)
{
Tcl_CreateCommand(interp, "mycmd", MyCmd, NULL, arg);
return TCL_OK;
}
int
Ns_ModuleInit(char *server, char *module)
{
...
Ns_TclInitInterps(server, AddCmds, mydata);
}
In AOLserver 2.0, this code would invoke AddCmds at startup for each
Tcl_Interp in the "pool" of interps for the virtual server.
In AOLserver 2.1 through 2.33, this code would invoke AddCmds once at startup
in the "master" interp of the virtual server, the command table and global
variables of which would be shared with all other per-thread "half interps"
in the virtual server.
In AOLserver 3.0 through 3.4, this code would invoke AddCmds once at startup
on the "template" interp, the commands and procs of which would be copied to
new per-thread interps when requested.
Finally, in AOLserver 4.0, this code will invoke AddCmds on each interp
created for the virtual server when requested, perhaps long after startup and
certainly long after the call stack of the function calling Ns_TclInitInterps
is gone (e.g., the Ns_ModuleInit).
So, sounds to me like ns_stats could come back into 4.x if you add an
"ns_stats cleanup" to flush the stats, add that to the ns_cleanup proc, and
write a custom Ns_TclInterpInitProc which creates the per-interp state and
command trace when enabled. You may want to store the state in Tcl "assoc"
data as is done for the NsInterp structure as well to ensure proper cleanup
at Tcl interp time and pass it via the StatsCmd ClientData as well, meaning
the Ns_Tls used in 3.x is probably not necessary.
-Jim
