I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't matter in this
context," because that seems to fix my problem.
Dr Wes Munsil wrote:
Please give me your advice.
I've instrumented TclBlend to look for the pattern of execution of
MonitorEnter/MonitorExit calls and have learned
Without having looked into the innerds of TclBlend's JNI implementation
(though it looks quite clean at least) I'd say that removing the monitor
calls and JAVA_LOCK are probably fine.
I say this because we have a decent size app (~250K lines of C/C++/Java)
that uses a JNI layer I wrote. I never
A small correction. My patch does NOT remove the monitor calls in
JAVA_LOCK/JAVA_UNLOCK. The patch fixes problems encountered if you load Tcl
into a running JVM, which is the opposite way of using TclBlend comparing
how you are using TclBlend.
I also think removing all instances of
Sorry, you are quite correct; I was not clear. When I refered to "Jiang's
patch," I actually meant "the patch at
http://www.mail-archive.com/tcljava@scriptics.com/msg00598/tclblend.patch, plus
Jiang's suggestion to remove the monitor calls from JAVA_LOCK and JAVA_UNLOCK."
Thank you for allowing
Mo DeJong wrote:
On Tue, 13 Jun 2000, Dr Wes Munsil wrote:
1) Tclblend_Init is never called. Consequently the call of MonitorEnter
in that function is never executed.
That does not seem right. The Tclblend_Init method should be
invoked by Tcl during the load command (like load
The patch I ended up with to solve the Solaris deadlock issue combines
Jiang Wu's patch and the removal of all MonitorEnter and MonitorExit
calls. The diffs between TclBlend 1.2.5 and my version are at
http://idd.com/~wes/tclblendpatch. Note also that the class
tcl.lang.NativeLock may now be
