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()".  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.

-- Jiang Wu
   [EMAIL PROTECTED]

> -----Original Message-----
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 19, 2000 11:05 AM
> To: Dr Wes Munsil
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] another deadlock
> 
> 
> On Mon, 19 Jun 2000, Dr Wes Munsil wrote:
> 
> > This one appears to be different. Vignette StoryServer 5.0, 
> Tcl 8.2.3,
> > TclBlend 1.2.5, JDK 1.1.8, SunOS 5.6. TclBlend patched as 
> described in
> > my last post. Little flexibility to upgrade to more recent 
> versions of
> > anything.
> > 
> > Every thread stacktrace that seems relevant is below. The
> > java_lang_UNIXProcess_run is presumably my call of 
> Runtime.exec ("env").
> > No idea why it is in sysMonitorWait. May or may not be 
> related to the
> > deadlock.
> > 
> > Thoughts, opinions, wild guesses encouraged.
> 
> I think this one is along the same lines. The finalizer thread seems
> to be called decrRefCount() which is calling FreeTclObject(). I
> think we need a more general solution to the problem of the
> finalizer thread walking into an interp at some random time.
> 
> Can we create a queue of objects that have been finalized?
> We could then clear this queue in a Tcl "after idle" call.
> 
> Should be make the gc thread block until a given Tcl event
> has finished? This would need to be done by adding an event
> to the Tcl event queue and then letting the GC thread go
> when Tcl was ready to process the event.
> 
> What do folks think of these approaches?
> 
> 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
> 

----------------------------------------------------------------
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

Reply via email to