On Tue, Feb 18, 2003 at 10:33:25AM -0500, Jim Davidson wrote:
> ns_after 1 {ns_thread begindetached [list atp_test foo bar]}
>
> This should create the thread 1 second after startup with the full
> environment. The reason is the scheduler has a call to Ns_WaitForStartup()
> at the top of the SchedThread main in nsd/sched.c so it won't process the
I tried this, still some problems, please see below.
> ns_after request until the server is fully initialized. Note that if your
> Tcl thread is long running, you'll need to do the right thing to manage state
> manually as it won't benefit from the regular cleanup/update effects of
> Ns_TclAllocateInterp/Ns_TclDeAllocateInterp as with ordinary transactions. A
> call to "ns_cleanup" or perhaps "ns_ictl update" in the body of your while
> loop may work. Unfortunately this stuff is not well documented or understood
> as most folks don't need to bother with it - check the code in nsd/tclinit.c
> and nsd/init.tcl for details.
?? Sorry, I don't follow. Why would any special manual cleanup in a
long-running detached thread be necessary? And this is completely
different from 3.x, right? I looked at the ns_cleanup, ns_ictl
update, etc. code but that wasn't enough for me to understand what's
going on...
Using ns_after 1 thing helped, but seemed to only let things get far
enough to expose additional problems. Now, I seem to have these two
problems:
- 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.
- Ns_TclInterpServer (called with a NULL Tcl interp), is segfaulting
when calling Tcl_GetAssocData.
[18/Feb/2003:16:51:57][14596.1][-main-] Notice: nssock: listening on 10.10.123.35:8075
[18/Feb/2003:16:51:57][14596.7][-driver-] Notice: starting
[18/Feb/2003:16:51:57][14596.7][-driver-] Notice: driver: accepting connections
[18/Feb/2003:16:51:58][14596.5][-sched-] Error: nsvapi: BB_NsvSet: Tcl_GetCommandInfo
says Tcl command 'nsv_set' does not exist!
[18/Feb/2003:16:51:58][14596.8][-thread8-] Error: nsvapi: BB_NsvExists:
Tcl_GetCommandInfo says Tcl command 'nsv_exists' does not exist!
[18/Feb/2003:16:51:58][14596.8][-thread8-] Error: nsvapi: BB_NsvSet:
Tcl_GetCommandInfo says Tcl command 'nsv_set' does not exist!
[18/Feb/2003:16:51:58][14596.8][-thread8-] Error: nsvapi: BB_NsvGet:
Tcl_GetCommandInfo says Tcl command 'nsv_get' does not exist!
Segmentation Fault (core dumped)
(gdb) bt
#0 0xff225ddc in Tcl_GetAssocData () from /usr/local/lib/libtcl8.4.so
#1 0xff352c6c in NsGetInterp (interp=0x0) at tclinit.c:518
#2 0xff352da4 in Ns_TclInterpServer (interp=0x0) at tclinit.c:670
#3 0xfee9870c in BB_GetBool (
The segfault is happening when I call call Ns_TclInterpServer, which
then dies when NsGetInterp calls Tcl_GetAssocData. Is this a bug in
Ns_TclInterpServer? Seems that it should be able to handle getting a
NULL interp...
Anyway, the segfault looks like another virtual server related issue.
I suspect that the problem is that I'm passing in a NULL Tcl interp to
Ns_TclInterpServer (which of course works fine in 3.x), but I haven't
tried changing my code to pass in the real Tcl interp yet.
// Code from my BB_GetBool function:
Ns_DStringVarAppend(&dsSection, "ns/server/",
Ns_TclInterpServer(NULL), "/module/nsmymodule",
NULL);
if ( Ns_ConfigGetBool(dsSection.string, key, &bool) == NS_FALSE ) {
bool = default_value;
}
char *
Ns_TclInterpServer(Tcl_Interp *interp)
{
NsInterp *itPtr = NsGetInterp(interp);
if (itPtr == NULL || itPtr->servPtr == NULL) {
return NULL;
}
return itPtr->servPtr->server;
}
NsInterp *
NsGetInterp(Tcl_Interp *interp)
{
return (NsInterp *) Tcl_GetAssocData(interp, "ns:data", NULL);
}
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com
