I don't think your Dr Wes Munsil's scenario is a problem. The patch is only applied to a CObject. A CObject is the Java wrapper for a C Tcl_Obj. A Java static object will not be (should not be) represented by a CObject. As a result, the normal GC should do the same thing as before for this native Java object. The TclBlend code seems to be careful enough that it won't create a TclObject that contains a CObject that contains another TclObject. Though there could be bugs in this area. If that happens, the error scenario can occur. The only issue with the patch is that it leaks C Tcl_Obj. I think this can be solved without rewriting the whole ref count stuff. -- Jiang Wu [EMAIL PROTECTED] > -----Original Message----- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 21, 2000 7:58 PM > To: Dr Wes Munsil > Cc: [EMAIL PROTECTED] > Subject: [Tcl Java] [Tcl Java] another deadlock > > > On Wed, 21 Jun 2000, Dr Wes Munsil wrote: > > > Let me run an error scenario by you concerning this patch > and a possible > > interaction with Java static variables. > > > > Scenario: A Java static object is returned to a Tcl script > by some TclBlend > > call, represented by the command name java0x4 (say). Much > time passes--many > > more objects are created, there are no more Tcl references > to the Java > > object, and its command name goes away. Finally, the same > Java static object > > is returned again, by the same TclBlend call. > > > > Since we are not doing the decrRefCount on finalize (it's > commented out), > > dispose() was never called, and the Java object is still in > the reflect table > > with the command name java0x4; so this is returned to the > Tcl script, which > > no longer recognizes the name java0x4. An "invalid command > name" error > > results. > > Could you create a small script and a .java file that reproduces this > error? I would love to have some good refcounting tests so that > we can be sure any ref counting changes that are made really work. > > > Is this possible? I am seeing something that behaves very > much this way, and > > this is my lame attempt to diagnose it. > > Yes, this is not just possible but highly likely. The patch I send you > was just a quick hack to avoid a deadlock. From your note, I assume > that it does in fact avoid the deadlock, which proves that it > was the GC thread running the finalizer method on the CObject class > that was causing the deadlock in the first place. To really > fix the problem correctly, we need to do a rather large redesign > of the ref counting system for Tcl objects used with Tcl Blend. > So the good news is we know there is a problem and we know what > the problem is, the bad news is that it is going to take > time to fix it properly. While we are at it, we should also > drop the ref counting stuff from Jacl where it makes sense. > The code shared between Jacl and Tcl Blend will need to use > ref counts because Tcl Blend needs them. > > Mo DeJong > Red Hat > > ---------------------------------------------------------------- > 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 > ---------------------------------------------------------------- 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
