On Wed, 14 Jun 2000, W. John Guineau wrote:
> 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
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 l
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 me
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 MonitorEnter
On Tue, 13 Jun 2000, 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 this. The deadlock seen
> in my code, and now in the TclBlend regression test
> AutomaticSignature.test
gt; Sent: Wednesday, June 14, 2000 7:40 AM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock
>
>
> I hope you will tell me "SOLUTION 1, and Tclblend_Init doesn't
> matter in this
> context," because that seems to fix my
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 learn
