On Mon, 19 Jun 2000, Jiang Wu wrote: > Would the GC problem still exist if the underlining Tcl is thread enabled? > In other words, is it OK to call "FreeTclObject()" from any thread in the > thread enabled Tcl? > > It may not be a good idea to block the GC thread. For this scheme to work, > one needs to make some assumption about how the GC works, which may not > apply to the various implementation of the JVM. > > I like the other approach. Tcl/TclBlend should clean up its own data in a > Tcl safe manner. This probably means that the user of TclBlend needs to > explicitly free Tcl objects using "TclObject.preserve()" and > "TclObject.release()". Tcl Blend users should be doing this already. > Then, when the Java GC is invoked to clean up the > associated Java object, the GC need not access any Tcl stuff. Though, I am > not sure about automatically creating a list of objects to be finalized. Perhaps if we let the GC thread access only 1 "Tcl thing", then we can make that single function thread safe so that both the GC thread and Tcl can call it at any time. This function could keep a linked list of Tcl internal reps that would need to be freed by Tcl. Of course, this means we would need a thread enabled Tcl. Mo DeJong Red Hat Inc ---------------------------------------------------------------- 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