On Tue, Feb 18, 2003 at 07:20:14PM -0500, Jim Davidson wrote:
> In a message dated 2/18/2003 5:53:54 PM Eastern Standard Time,
> [EMAIL PROTECTED] writes:
> > - The BB_Nsv* C functions I've created in my nsvapi.c still aren't
> > working right in some cases, Tcl_GetCommandInfo is still claiming that
> > "nsv_set", etc. don't exist. This is despite the fact that the thread
> > calling these is now being spawned AFTER full server initialization.
> Are you using Ns_TclAllocateInterp to get your interp with a NULL server arg
> within your Ns_ModuleInit? This would provide you a non-virtual server
Nope. Mostly all I do in my Ns_ModuleInit is init a Tcl hash table,
name some mutexes, and create a Tcl command. Like this:
static int BB_interpInit(Tcl_Interp *interp, void *data)
{
Tcl_CreateCommand(interp, "myapi", BB_TclCmd, NULL, NULL);
return NS_OK;
}
int Ns_ModuleInit(char *server, char *module)
{
Tcl_InitHashTable(&my_static_hashtable, TCL_STRING_KEYS);
Ns_MutexSetName2(&foo_lock, "BB", "my_hashtable");
Ns_MutexSetName2(&bar_lock, "BB", "serialize_external_api_calls");
return Ns_TclInitInterps(server, BB_interpInit, NULL);
}
Should I be doing an special interp initialization other than that?
> > - Ns_TclInterpServer (called with a NULL Tcl interp), is segfaulting
> > when calling Tcl_GetAssocData.
> Ns_TclInterpServer shouldn't be called with NULL - it needs to dig out the
> server from the interp. I believe 3.x just returned a global variable.
Yep, passing a real Tcl interp pointer to Ns_TclInterpServer fixed
that problem.
> it started looking messy and hard to maintain. I'm guessing you can fix up
> your code pretty quick to deal with the virtual servers and it should work
> with 3.x as well.
Yes, I suspect that's the case too. I'm getting closer, anyway.
Thanks for all the help and background info!
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com
