Re: [naviserver-devel] ns_moduleload confusion?

[Stephen D. <sd...@gm...>]

On 10/19/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi everybody!
>
> The new ns_moduleload command seems to add some confusion
> to what is being done on the virtual server/interp
> initialization, unfortunately.
>
> In the way it works now, modules are loaded from the
> virtual server initialization script. At that time the new
> ns_moduleload is used to load the module (and invoke its
> Ns_ModuleInit call).
>
> In the way it worked before, modules were loaded by the core
> *before* the script got executed.
>
> This has a very fine, yet problematic side effect (which is
> BTW hitting  me very hard):
>
>    If I place some Tcl commands in a module and would
>    like to use those commands in the server init script
>    I'm out of luck :-(
>
> By coding my modules to use Ns_TclInitInterps() I was
> simply adding a callback to be run each time an interp
> was created for the thread. Now, during the startup when
> the virtual server scripts are executed, the modules were
> loaded by the server, and hence available in the interp
> which was runnign the init script. This is  because a new
> interp was created and inited before the script was run.
>
> Now, the init script itself loads the module, the module does
> register that callback but this is activated way later,
> (for other interps, threads) hence my init scripts break.
>
> I would not like to recompile all my modules. Even more,
> it might be even impossible to do that because of the
> existing field installations. So I have a serious backwards
> compatibility problem.
>
> Ah... just of curiousity, I inspected the nslog module and
> there you go: the same thing is happening. This module
> adds new Tcl command [ns_accesslog] which is inaccessible
> during the evaluation of the virtual interp init script,
> ALTHOUGH the module has been loaded with the ns_moduleload
> BEFORE this command is used for the first time.
>
> I believe we will have to reconsider the usage of ns_moduleload
> mechanism ...
>
> Otherwise, what are my options?


My fault, sorry.

Looks like I assumed caling a module's init proc was enough to fully
initialize.  It's not.  The commands are added from interp traces
(CREATE and/or ALLOCATE).

I've changed the code to run the callback immediately (just CREATE and
ALLOCATE traces).  Because the tracing API is available only before
startup, and because the module is loaded from ns_moduleload, which
necessarily requires an interp, this should add the modules commands
and other data to the current bootstrap interp.

This is relevant to the bootstrap init.tcl file and to module which
have both a binary *.so file and *.tcl files when the *.tcl files call
commands registered from the binary.


Does this work for you?