I've been investigating the thread cleanup, and it appears that thread
cleanup handlers created with Tcl_CreateThreadExitHandler are only
called when tcl is shutting down. This is true at least for tcl8.3.2.
I haven't looked at tcl8.4.
There is an experimental tcl thread interface in tcl8.3.2 that allows
a user to control tcl threads from within tcl scripts. I understand
that this interface will be included in tcl8.4, and threads created
with this interface will call the cleanup handlers created with
Tcl_CreateThreadExitHandler. So there should be no problem for
threads created within tcl.
This is all well and fine, but the problem is that tclblends design
conflicts with the order of the cleanup handlers. When a tcl thread
exits, it calls these registered cleanup handlers, and then it
deletes the interpreter for the thread. The problem in the current
design is that the jvm thread is detached, before the interpreter is
destroyed. When the intrepter is destroyed it cleans up all of the
remainined Tcl_Obj's which results in a call to FreeTclObject.
FreeTclObject then tries to call the release method for the TclObject
that it represents, and this results in a segfault, because the jvm
has already detached from the current thread. I came this while
testing in aolserver, and from looking at the tcl source, it appears
that you will have the same problem with the regular version of
tclblend when using the thread interface in tcl8.4.
Threads created from java will not get segfaults, because the cleanup
routines will not be called. Of course, you will then have memory
leaks.
-Dan
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
