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
