Re: [tcljava-user] JAVA_LOCK problem in TclBlend 1.2.6

[Mo D. <md...@cy...>]

On Tue, 14 Nov 2000, Udi Margolin wrote:

> Hello,
> 
> I'm trying to invoke a TCL command from a Java class in a JVM loaded as a
> java package to the TCL shell.
> If the java command is called from another TCL command invoked from the
> shell, the command is called properly.
> 
> When trying to invoke the command from a Java GUI (button) the process gets
> stuck. After some investigation, it looks like the JAVA_LOCK() macro in the
> javaInterp.c (in the Java_tcl_lang_Interp_eval procedure) does not return.
> 
> When trying to remove the JAVA_LOCK() command (and the matching
> JAVA_UNLOCK()), the command is processed but the behaviour is not smooth
> (probably due to the lock which was removed).
> 
> Looks like another thread is locking the NativeLock but I have no idea which
> one.
> 
> Any Ideas ?


I am willing to bet that you are calling interp.eval() directly
from another thread (the AWT thread in this case).
This is one of the most common "beginner errors".
In Tcl, you synchronize as events are added to the
Tcl event queue, not on every use of a shared
resource. In practice, this works far better than the
fine grained per object synchronization provided by Java.

I would take a peek at this writeup if I were you.

http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html

I tend to advocate this simlified way of queuing an event:

http://www.mail-archive.com/tc...@sc.../msg00647.html


All of this is not documented very well, would you care
to help? We could really use some "getting started" or
"tutorial" documents. Currently, we only have
reference documentation.


There is also the chance that you are running into a known
problem in Tcl Blend 1.2.6 where it deadlocks because the
GC thread tries to grab the lock. This problem has been
fixed in the 1.3 development version but I have not ported
it back to the 1.2 stable tree because there do not seem
to be many folks running into it. You might want to try
the development version if the above suggestions do not
fix the problem you are running into.

Mo DeJong
Red Hat Inc