Menu
▾
▴
#68 Ns_TclInitServerInterps
Modules may call the function Ns_TclInitInterps to
register a callback to add commands to an initialising
interp. The sequence of events goes: register base
AOLserver commands; run module callbacks to register
commands; register AOLserver virtual server commands.
This patch adds a new function Ns_TclInitServerInterps
with which loadable modules can register callbacks
which run just after the AOLserver virtual server
commands are loaded.
You can sorta kinda get the same resul by registering
an NS_TCL_TRACE_GETCONN trace, because by necessity
that will also be a virtual server interp. However,
that trace gets run on every call to GetConn, not once
per interp, so you have to maintain state and to make
sure you only run things once which gets pretty ugly.
In summary, this patch adds one more trace point in the
lifetime of an interp which modules can hook into.
Ns_TclInitServerInterps() function
Logged In: YES
user_id=95086
Stephen,
Is there any practical benefit of a real-life example why
anybody would like/need to intercept at that point?
IIRC, Jim has added some alternative to initializing the
interps some time ago. I can't now exactly remember
where it was, but it is basically geared towards leaving
modules initialize the interp by themselves. I yet have
to make some digital archeology to get this out, but
there is such a thing already there.
Logged In: YES
user_id=87254
I need to register a Tcl command trace on some AOLserver
core commands which are 'server commands', and are therefore
loaded after the call to my Ns_TclInitServer callback fires.
At that point, commands like ns_return etc. just don't
exist so there's nothing to trace.
Also, symetry :-). The generic/server command split exists
and is exploited by the core, this just exposes it to modules.
Logged In: YES
user_id=95086
Basically, this means:
1. AS: load generic (server-wide) commands
2: MODULES: load generic module commands
3 AS: load per-virtual-server commands)
4. MODULES: load per-virtual-server module commands
To be clear: your patch just adds the 4. right?
Logged In: YES
user_id=87254
That's right.
Logged In: YES
user_id=95086
You know what, Stephen?
I will give this a second thought, although I have no
bad feelings about it now and here.
Based on that I will just go and eventually commit
this into the 4.1 head branch.
If ANYBODY complains about that, then it is very clear
that this SOMEBODY is not at all interested in having
any contribution to the AS whatsoever.
In this case I will declare the project DEAD for myself
and mind my own little business.
I think you understand this. I'm deliberately writing
this here so we have a *written* record of the issue
in case it comes up sometimes in the future.
Logged In: YES
user_id=21885
Reviewed the patch and it looks good. I don't know if I like
the name "server" for the trace, but I can't think of a better
suggestion. Maybe "virtual" to remind folks that the trace
only gets run if you have a virtual server configured. I'll let
someone else decide.
Could you also update the documentation on the wiki:
http://panoptic.com/wiki/aolserver/ns_ictl
It seems I totally missed the [ns_ictl trace] subcommand
entirely.
Also, for completeness, should this RFE add [ns_ictl onserver]
(or [ns_ictl onvirtual], however it gets decided) as well?
Logged In: YES
user_id=87254
There is always at least one virtual server configured
(which I guess makes it not so virtual...), so there is no
distinction to make. This is actualy tricky terminology.
Perhaps we should follow the example of zeus.co.uk and call
a configured server which can load modules, have it's own
Tcl library etc. a Virtual Server, and call a host-header
mapped server a Sub Server? Anyway...
Neither the 'getconn' nor 'freeconn' traces are exposed as
ongetconn or onfreeconn, and I think the 'server' trace
falls into a simillar class. If you think it should be
added though, I'll add it.
I'm not attached to the name 'server' myself. It's tough to
think of an apropriate single word verb. However, I imagine
the C API, which is named apropriately, to be the most
common usage pattern, so I don't think it matters much.
Logged In: YES
user_id=21885
Also, in your proposed implementation, registering a "server"
trace isn't server-specific. In which case, it's equivalent to
the init/create traces, from what I can tell. If it's meant to
register a callback for a particular server, shouldn't the server
name be a required parameter as well? Is there meant to be
one trace used for every virtual server defined, or should you
be able to register separate traces for each virtual server?
And as you say, "for symmetry", shouldn't there be a server-
specific delete trace, too?
I'm being facetious here. While I have nothing against this
patch in principle, I have a hard time finding practical
applications. Your one example doesn't justify this change:
you could write the code to register the Tcl command traces
in a .tcl file and place it in the server's private Tcl library dir.
and (I believe) would have the same effect as this RFE.
I'll clarify: I'd like to see an example usage of the feature
proposed in this RFE that without it, would make implementing
a particular feature of an actual web application under
AOLserver impossible.
Of course, you or Zoran are free to implement and commit the
functionality proposed in this RFE regardless of whether such
an example exists, but I'd feel better having at least one to
justify adding this feature.
Logged In: YES
user_id=87254
There's no such thing as a non server specific interp. If
you look closely you'll see that NsTclICtlObjCmd, which
implements the ns_ictl command, does in fact register it's
traces on a per virtual server basis.
I don't see the symetry in a delete trace for server
commands. AOLserver doesn't already have a mechanism for
this, unlike the creation case we're discussing here,
probably because the generic delete trace is sufficient.
Can you think of an example use case for which you'd need
such a feature?
The initial interp is used only as a template and is
destroyed after the server starts. Any command traces
registered for a C based command will be destroyed along
with the interp. It is therefore not possible to achieve
this from within the server's private tcl library.
Logged In: YES
user_id=21885
I'm uploading a file (nsfoo.tar.gz) which is a minimal "nsfoo"
module which registers a Tcl command "ns_foo" from a loaded
C module.
I'm including the slightly modified sample-config.tcl named rfe-
1011351-config.tcl which simply adds nsfoo${shlibext} to the
list of modules to load, as well as uncommenting the nscp
config to enable it. I also define the private Tcl library as
the "/tmp/foo" dir. Copy the included "nsfoo.tcl"
to "/tmp/foo/nsfoo.tcl". Build and install the module.
Start the server. You should see:
[19/Aug/2004:01:32:01][29651.1076558336][-main-]
Notice: nsfoo.tcl loaded
to ensure that the private Tcl library was configured
correctly, and that nsfoo.tcl was sourced at start-up. It
uses [ns_ictl oncreate] to register the Tcl command
execution trace which calls the [ns_foo_trace] proc which is
defined in the nsfoo.tcl file.
From the control port, we observe:
server1:nscp 1> trace info execution ns_foo
{enter ns_foo_trace}
server1:nscp 2> info exists ns_foo_trace
0
server1:nscp 3> ns_foo
foo
server1:nscp 4> info exists ns_foo_trace
1
server1:nscp 5> set ns_foo_trace
1971910154 {ns_foo enter}
This is off a stock AOLserver 4.1.0a (CVS HEAD) build.
I'm still unclear as to what additional functionality this RFE
provides. If I wanted to avoid the nsfoo.tcl file and do
everything from within C, I could have by calling
Ns_TclRegisterAtCreate().
Clearly I'm missing the point and I'd like an example usage of
your proposed functionality using the patch you've supplied
that demonstrates something useful that cannot be done
without the patch. I'm obviously not seeing it ...
Logged In: YES
user_id=87254
Again, there are two classes of C-implemented Tcl commands
in AOLserver: generic commands which are loaded into all
interps, which includes commands registered by loadable
modules and builtins like ns_info, ns_log, ns_config; and
server commands which includes things like ns_return,
ns_conn etc.
Your ns_foo command is generic. It is defined before your
oncreate script runs and therefore can be traced. Server
commands are loaded after oncreate scripts run, so cannot be
traced.
My patch adds the 'server' trace, which runs after server
commands are loaded.
I wish to trace server commands.
Logged In: YES
user_id=95086
The "I wish to trace server commands" is pretty legitime
requirement and obviously exposes a hole in the current
design. I see no problems adding this feature.
Stephen, you might perhaps update the docs of the ns_ictl
to reflect this change.