> -----Original Message----- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 19, 2000 1:15 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] another deadlock > > Good point. I think it might actually be better to put a panic() > in the finalize() method for a Tcl object, that way we will know > that someone forgot to decr a ref count instead of silently leaking > Tcl objects. This sounds good to me. If we want to do the auto free for TclBlend users, this may be the place to add the internal object to the queue you were talking about and trigger a TclEvent to free these internal object in a Tcl safe way. > I was under the impression that the interp would always do a > preserve() for you because of this exact case. When a new interp > result is set, it would call release(). Are you referring to the native C Tcl interpreter? The C interp might just do what you described. But since the resulting Tcl object is wrapped inside a Java CObject instance for TclBlend, the CObject increments the native Tcl object's ref count by one. Even if the C interp automatically decrement the Tcl object's ref count when setting the next result, the Tcl object won't be free'ed until the Java CObject decides to free the object also. -- Jiang Wu [EMAIL PROTECTED] ---------------------------------------------------------------- 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
