You cannot share Tcl objects across threads - not even lists, ints and strings.I had no idea... How should I deal with that string object's garbage collection? Perhaps I shouldn't call Tcl_IncrRefCount on it and that's enough to prevent a leak.
Actually, if you don't call IncrRefCount, you will probably get some error somewhere - since refcount can't go to -1, at least in debugging mode in Tcl 8.4.
If you don't DecrRefCount, you will leak, but probably be ok.
Another question: is it OK to share Tcl interps between threads?
No. It is not OK - an interp (as well as any Tcl_Obj) is bound to a thread (note - Tcl_Obj is bound to a thread, not an interp :).
If you really need to execute bytecode, then consider:
1/ using a separate thread only to create and delete Tcl_Obj - this should work a bit better, but not sure if it will work now and if it will fail in future Tcl releases (this is very tricky)
2/ using a separate thread to evaluate the bytecode - when using Tcl 8.3.4 and 8.4.x, you can easily use Tcl_Async* to communicate between threads. It's not hard, the only problem is that you cannot send (well, sometimes you can, but it's a hack and shouldn't *ever* be done) Tcl_Obj across threads, so it will cause a large slowdown if you plan on working with larger (over 1000 elements) lists. Otherwise, you'll be ok by using Tcl_GetStringFromObj(), cloning and sending that.
-- WK
-- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
