On Mon, Feb 17, 2003 at 06:44:05PM -0500, Andrew Piskorski wrote:
>Also, the Tcl procs I've defined don't seem to work in non-connection
>threads either. I definitely get "invalid command name" errors both
>in the -main- and various detached threads (e.g., -thread6-,
>-thread7-). Why? Do I need to configure something different for
>AOLserver 4.0?
Ah, more detail on this part of the problem:
>From a connection thread, this works fine:
ns_thread begindetached [list atp_test foo bar]
But if I issue that exact same command from one of my Tcl library
files, during AOLserver startup, but still AFTER defining the atp_test
proc, the above fails with e.g.:
[17/Feb/2003:19:01:18][2264.8][-thread8-] Error: invalid command name
"atp_test"
invalid command name "atp_test"
On AOLserver startup, I definitely need to spawn some threads which
run Tcl procs I've created. How do I go about doing this in AOLserver
4?
Hi,
The problem is the code in nsd/tclthread.c does not wait for the virtual server to be setup before starting the thread is created so you get a "half baked" environment. Try this hack:
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 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.
Otherwise, I agree with your previous message that this stuff is messy. Reasons include both the non-standard manner in which Tcl is initialized at startup and because of the added complication of virtual servers. I think it'll take a few more releases to clean this up in stages.
-Jim
