[Tcl Java] Tcl Blend vs JACL
We have a medium sized system (~250K lines of C++ and Java) that we want to graft Tcl scripting into. The place where we would integrate scripting is all Java code. I see the recommended solution in this case is to use JACL, but for performance reasons (and other factors) I would prefer to use Tcl Blend. We already have a fairly significant JNI interface to common C++ code, so I'm quite familiar with JNI at this point (I see Tcl Blend also uses JNI.) My plan is to load the Tcl interpreter from within Java, and then interact with it from Java. We would then write Tcl extensions that essentially wind thier way back into our Java code, and therefore have access to all the functionality we already have. We will also need to single step the interpreter and view/modify variables from within the Java code. Am I asking for trouble by "going against the grain" on this? john 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
[Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Well, if I use the Java package, then the Tcl code would not have access to the same run-time instance of the JVM that our code is running in, right? (starting our Java code from Tcl is, unfortunetly, not an option.) Or am I missing something here? My assumption was that starting a Tcl interpreter from within a given JVM would cause the Tcl Blend package on the Tcl side to use the existing JVM and not create a new one. My goal is to: 1. start n number of Tcl interpreters from a Java application (n usually 1 or 2) 2. load and execute a Tcl script from within Java 3. load and *debug* a Tcl script from within Java (i.e. "single step" the interpreter in trace mode, so the user can click a UI button (from a Java client running across a TCP/IP link to the JAVA server code mentioned above) to step through a Tcl script, examining variables along the way. 4. Write Tcl extensions in Java (or C/C++,) which can then access the JVM, and hence all the Java Server code. I suspect for 3. I will need to extend Tcl Blend's JNI implementation to provide Java side access to Tcl_CreateTrace et al. john > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff > Sturm > Sent: Wednesday, May 24, 2000 2:45 PM > To: W. John Guineau > Cc: [EMAIL PROTECTED] > Subject: Re: [Tcl Java] Tcl Blend vs JACL > > > "W. John Guineau" wrote: > > My plan is to load the Tcl interpreter from within Java, > > and then interact with it from Java. We would then write > > Tcl extensions that essentially wind thier way back into > > our Java code, and therefore have access to all the > > functionality we already have. We will also need to single > > step the interpreter and view/modify variables from within > > the Java code. > > You can certainly write extensions this way, but why not use the java > package, which is reflection based, instead? I find it easier to just > invoke my methods directly from Tcl than to try to write a custom > extension. > > -- > Jeff Sturm > [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
[Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Ah, thank you for the document pointer! This looks to be the motherload of Tcl Blend/JACL info! john > -Original Message- > From: Jiang Wu [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 24, 2000 2:24 PM > To: 'W. John Guineau'; [EMAIL PROTECTED] > Subject: RE: [Tcl Java] Tcl Blend vs JACL > > > You are certainly "going against the grain" right now :) But I am hoping > more people will use TclBlend this way. > > We are doing something similar right now with TclBlend (1.3 + > some patches) > with JDK 1.2. I am not sure what you mean by "single step the > interpreter". > You can certainly set/get/call Tcl variables and commands within the Java > code. We also have a socket connection for the embedded Tcl interpreter. > We use telnet to access the interpreter interactively for > debugging. We can > also use Visual Cafe to single step through any Java portion of > the program. > > There are some potential threading problems. You also need to patch the > existing TclBlend. You may want to take a look at: > > http://www-cs-students.stanford.edu/~jwu/Using_Tcl_in_Java.html > > which discuss how to embed Tcl in Java. > > -- Jiang Wu >[EMAIL PROTECTED] > > -Original Message- > From: W. John Guineau [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 24, 2000 2:09 PM > To: [EMAIL PROTECTED] > Subject: [Tcl Java] Tcl Blend vs JACL > > > > We have a medium sized system (~250K lines of C++ and Java) that > we want to > graft Tcl scripting into. > > The place where we would integrate scripting is all Java code. > > I see the recommended solution in this case is to use JACL, but for > performance reasons (and other factors) I would prefer to use Tcl > Blend. We > already have a fairly significant JNI interface to common C++ code, so I'm > quite familiar with JNI at this point (I see Tcl Blend also uses JNI.) > > My plan is to load the Tcl interpreter from within Java, and then interact > with it from Java. We would then write Tcl extensions that > essentially wind > thier way back into our Java code, and therefore have access to all the > functionality we already have. We will also need to single step the > interpreter and view/modify variables from within the Java code. > > Am I asking for trouble by "going against the grain" on this? > > john > > > 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
[Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Jeff, sounds like your experience confirms my initial analysis - It's a safe bet to go the Java -> Tcl Blend direction. BTW - this work is for JPL (Jet Propulsion Laboratory) - so you can add JPL to the list of "large corporate/gov't users of Tcl and Tcl Blend ;) We will be using Tcl to script our ground command and control system for a new satellite due to launch in a few months. We will be doing the first ever "lights out" (no humans) automation of a satellite! john > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff > Sturm > Sent: Wednesday, May 24, 2000 3:29 PM > To: W. John Guineau > Cc: [EMAIL PROTECTED] > Subject: Re: [Tcl Java] Tcl Blend vs JACL > > > "W. John Guineau" wrote: > > Well, if I use the Java package, then the Tcl code would not > have access to > > the same run-time instance of the JVM that our code is running > in, right? > > I don't see why not. There is only one JVM per process anyway. (That > is a limitation of the Sun JVM.) I'm not familiar with the code, but by > executing AttachThread the Tcl interpreter can easily get a handle to > the existing JNI environment. > > > (starting our Java code from Tcl is, unfortunetly, not an option.) > > Understood. I am doing what you describe, except I haven't attempted to > single-step the interpreter and I'm currently using Jacl, not TclBlend. > > I have a Java servlet that creates a pool of interpreters, each running > in its own thread. Each interpreter uses the java package and calls > back to Java methods. I haven't yet needed to write any custom > commands, the java package is a "swiss army knife" that way. > > > -- > Jeff Sturm > [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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL
Wow, same day response, and no noise! (oops ;) Great email list. > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 24, 2000 5:13 PM > To: W. John Guineau > Cc: Jiang Wu; [EMAIL PROTECTED] > Subject: Re: [Tcl Java] RE: [Tcl Java] Tcl Blend vs JACL > > > There are a bunch of posts on this Jacl vs Tcl Blend > thread so I will try to respond to points from each. > > > W. John Guineau Wrote: > > > We have a medium sized system (~250K lines of C++ and Java) that > > we want to graft Tcl scripting into. > > > > > > Am I asking for trouble by "going against the grain" on this? > > > The only problem you are going to run into is that Tcl Blend > currently needs a patch before it can be loaded directly into > Java. This patch will be merged into the CVS verison of > Tcl Blend very soon. There is some ongoing discussion about > how to do this best, so feel free to jump in with any > thought you might have on JAVA_LOCK or any other Tcl Blend > related issues. Hmm, this patch wouldn't happen to fix the following odd error I'm currently chasing (below), would it? = C:\JTCCSRoot\ui\Automation>set bld=debug C:\JTCCSRoot\ui\Automation>set path=c:\jdk1.3\jre\bin;c:\jdk1.3\jre\bin\classic;C:\tcl\tcl8.3.1\win\debug;c :\tcl\tcl8.3.1\lib\tclblend;.;C:\WINNT\system32;C:\WINNT; C:\JTCCSRoot\ui\Automation>set cp=C:\jdk1.3\jre\lib\rt.jar;.\classes;c:\tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl \tcl8.3.1\lib\tclblend.jar C:\JTCCSRoot\ui\Automation>java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) C:\JTCCSRoot\ui\Automation>java -classpath C:\jdk1.3\jre\lib\rt.jar;.\classes;c: \tcl\tcl8.3.1\lib\tcljava.jar;c:\tcl\tcl8.3.1\lib\tclblend.jar scriptmanager.Scr iptManager Exception in thread "main" java.lang.NullPointerException at tcl.lang.Interp.create(Native Method) at tcl.lang.Interp.(Interp.java:130) at scriptmanager.ScriptManager.main(ScriptManager.java:24) EXP: tcl.lang.TclRuntimeError: could not find class java/lang/Object. Check that your path includes the directory where tclblend.dll resides. Try looking in the directories under the value of tcl_library, currently: Currently, the CLASSPATH environment variable is not set. = > I think you will find that in time, you > will toss out all your other JNI code and just use Tcl Blend > to do the "nasty JNI work". It is much easier to use Tcl or > IncrTcl to interface with C or C++ code. Well, I doub't I'll toss the existing JNI code (read: I doub't I would get *paid* to!) but certainly sounds like a plan for any future JNI territory. Pulling one's own teeth would be more enjoyable than JNI ;) (well, maybe not quite that bad) > > Jeff Sturm Wrote: > > > You can certainly write extensions this way, but why not use the java > > package, which is reflection based, instead? I find it easier to just > > invoke my methods directly from Tcl than to try to write a custom > > extension. > > W. John Guineau Wrote: > > > Well, if I use the Java package, then the Tcl code would not > > have access to > > the same run-time instance of the JVM that our code is running in, > right? > > (starting our Java code from Tcl is, unfortunetly, not an option.) > > Or am I missing something here? > > The java package is simply a library of utility commands that wrap > the java.lang.reflect package. You can use the java package in both > Jacl and Tcl Blend. Think of it this way, the java package is an API > that gives you the ability to dynamically invoke Java methods and > create Java objects from inside Tcl code. Both Jacl and Tcl Blend > provide an implementation of the Java package, but the code is > actually shared and does not "require" anything other than a JVM. > > So the answer is, you are both right. One could write all code > that interacts with the JVM using the java::* Tcl commands, or > you could write a Java extension that does the interaction. But can the Java-based Tcl extensions "turn around" and call methods and access data of classes resident in the original Java VM instance (i.e. from where the Tcl interpreter was started via Tcl Blend/JNI)? In other words: I want a Java application to create a Tcl interpreter and then have the Java extensions in that Tcl interpreter access objects/data in the "parent" Java application. >From what I've read so far, I believe the answer is yes, but a sanity check is always good insurance. john --
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
Am I confused here?
I am currently loading Tcl Blend into Java in the sense that from a live
Java VM, I call 'import tcl.lang.*; Interp tclInterp = new Interp()' etc.
and I am able to interact with the C based Tcl interpreter, have dynamically
loadable extensions (written in Java) that run in the context of, and have
complete access to, all of my existing run-time Java code/data. The Tcl
scripts, using an extension created on the Java side:
try {
Class c = Class.forName( "CoreTclExtension" );
Command o = (Command)c.newInstance();
m_tclInterp.createCommand( "satlink", o );
} catch( Exception e ) {
System.out.println( "createCommand Failed: " + e );
}
can query, manipulate etc the live Java code, in the context of the Java VM.
Of course, I must be careful on exactly how I handle threading, but it seems
to work fine so far. I'm using Tcl Blend 1.2.6 with the various patches, Tcl
8.3.1 and JDK 1.3 all on Windows 2000, built using Visual C++ 6.x using
"Makefile" wrapper projects.
I suspect the original poster's problems relate to the native library search
path on his Unix system. On windows, you need to have the Tcl.dll
and TclBlend.dll files on the "PATH" as well as the corresponding .JAR files
on the Java CLASSPATH.
john
P.S. How can I get access to the 1.3 beta 'distribution' on a Windows
environment (i.e. I don't use CVS)
> -Original Message-
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 29, 2000 3:41 PM
> To: Zhumei Wang
> Cc: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
>
>
> On Mon, 29 May 2000, Zhumei Wang wrote:
>
> > Hi,
> > I am new to TclBlend. When I tried to run the small example from
> > http://dev.scriptics.com/man/java1.1/TclJavaLib/Interp.htm#M25
> > I got the following message:
> >
> > SIGSEGV 11 segmentation violation
> > si_signo [11]: SEGV
> > si_errno [0]:
> > si_code [1]: SEGV_MAPERR [addr: 0x4]
> >
> > stackpointer=FFBEE1D0
>
> ...
>
> > [1] tcl.lang.Interp.create(Native Method)
> > [2] tcl.lang.Interp.(Interp.java:130)
> > [3] jamesxxx.main(jamesxxx.java:8)
> > ---
>
> It looks like you are trying to load Tcl Blend into java.
> The existing 1.3 version of Tcl Blend is going to support
> this soon, but it does not work right now. You are of course
> welcome to join the discussion on how to fix this properly,
> see the mailing list archive for info.
>
> To get it working you need to start Tcl first and then load
> Tcl Blend (and the JVM) into a Tcl process. On UNIX systems,
> the "make install" rule creates two shell scripts that can
> be used to start a "Java enabled" version of tclsh or wish.
>
> Go to the bin directory where you installed Tcl Blend and
> note the jtclsh script. Then type these commands to run your
> example.
>
> cd $exec_prefix/bin
> ./jtclsh
> % package require java
> % java::call test main [java::null]
>
>
> I hope that helps
> 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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
I haven't gone much past tracking where JAVA_LOCK is in the code, and a cursory glance on what it's doing. With the Java <-> Tcl Queue, I don't see any reason to artificially tie up the JNI layer with more locking - only where appropriate within the JNI/C code itself. However! The one place you DO need locking is in the [Interp] callbacks. Concider that Interp is calling into pure Java code, with access to pretty much everything any other code running in that JVM does. If that "callback" accesses any data shared in the *Java* environment (with other Java threads etc) then there needs to be protection there. What I do in our other Java <-> JNI interface is to provide a shared Mutex (created in WIN32) that a JNI (callback) thread must aquire before making a callback. Likewise, the Java side code must respect the mutex for access to any shared data/objects etc. I haven't gotten that deep into Tcl Blend yet, so I don't know what it does in this regard. john > -Original Message- > From: Mo DeJong [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 29, 2000 6:29 PM > To: W. John Guineau > Cc: [EMAIL PROTECTED] > Subject: [Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem > with creating Interp object > > > On Mon, 29 May 2000, W. John Guineau wrote: > > > Mo, > > > > Since it's in my best interest, I can probably help with: > > > > 4. Merge the rest of Mr. Wu's patches for Tcl Blend. > > > > Is there a simple way for me to access the online CVS repository from > > Windows? I do have a dual-boot system with Linux (RedHat 6.2) > but my impetus > > is for work, which has a Windows platform requirement. > > > > I could also do a sanity check on the JAVA_LOCK stuff as I've done a > > considerable amount of multi-threaded work and may have some > insights (as an > > outsider) into the issues with Tcl Blend. > > > > john > > > That would be great. I think both Jiang, Scott, and I > are in agreement that the JAVA_LOCK stuff in the JNI > methods do not do anything useful. I think they were > originally added before the Notifier class was part > of Jacl and Tcl Blend. The Notifier class should > be the sole synchronization point for adding an > event to the Tcl event queue. The event is then > pulled off the queue by the dedicated "event thread" > and all command invocations after that are > unsynchronized. This is a good thing because you > end up with really low synchronization overhead. > > Currently, both the Tcl Blend and Jacl versions > of the notifier seem to be thread safe, so it > looks like you can just strip out all of the code > that has anything to do with JAVA_LOCK. This > JAVA_LOCK thingy is a big global lock that seemed > to be needed in the old days of Tcl 8.0, but the > 1.3 version of Tcl Blend only supports Tcl 8.3 > and Tcl 8.4 so that is no longer a concern. There > is also global lock inside unix/unixNotifier.c > and win/winNotifier.c that should only be used > when Tcl is compiled without thread support. > More detailed discussion of these issues > can be found in the mailing list archive. > > The best way to get CVS access on a windows > machine is to install Cygwin. You are going > to need cygwin to build Tcl Blend on windows > anyway, so you should just grab it now. > Your best bet is to just get it from a mirror. > > Download the installer. > > ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest/setup.exe > > Run it and then point it at a mirror like > > ftp://ftp.freesoftware.com/pub/sourceware/cygwin/latest > ftp://ftp.sunsite.utk.edu/pub/cygwin/latest/ > > Then grab the soure for CVS and run ./configure. It should > just configure and compile out of the box. > > Of course, it might be easier to just use a regular > Unix box running samba and just mount that over > the network on windows. That is what we do at work. > Actually trying to use windows to do any sort of > development work is much harder than developing > software to run on windows. > > 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
[Tcl Java] RE: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with creating Interp object
Zhumei, You definetly need the patches to 1.2.6 to even get started. I can build Tcl and Tcl Blend from inside Visual C++ 6.0 using what VC++ calls a "makefile wrapper" project. Basically you can mess with a (somewhat) standard makefile and VDC++ will just run NMAKE for you. Works fine. john > -Original Message- > From: Zhumei Wang [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 29, 2000 10:03 PM > To: Mo DeJong > Cc: W. John Guineau; [EMAIL PROTECTED] > Subject: Re: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] problem with > creating Interp object > > > Wow, what a mail list! I asked one question and got so many answers at the > same day. I love it. Thanks guys. > > Actually the answers from both of you are all I needed. I made that piece > of code work in tcl shell . What I am trying to do now is to embed a tcl > interpreter in java. It seems to me that I am going to do the same thing > as John does. Eventually I am going to create a group of commands over a > java application. Hopefully I can continue get help from you guys. > > Thanks again. > > Zhumei > > 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
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] what I now know about the deadlock
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 use locking in the JNI layer (in general) and have multithreaded access without any apparent problems (the JNI part is the backend of a Java based server that provides access to common C code.) john > -Original Message- > From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]] > 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 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 this. The deadlock seen > > in my code, and now in the TclBlend regression test > > AutomaticSignature.test on Solaris with native threads, has these > > characteristics: > > > > 1) Tclblend_Init is never called. Consequently the call of MonitorEnter > > in that function is never executed. > > > > 2) Although Jiang's patch removes the MonitorEnter and MonitorExit calls > > from JAVA_LOCK and JAVA_UNLOCK, there are still other calls of > > MonitorEnter and MonitorExit: they occur in Exit/Enter pairs in > > JavaIdleProc, JavaTraceProc, JavaCmdDeleteProc, JavaCmdProc, > > JavaEventProc, and JavaTimerProc. > > > > 3) The sequence of events leading up to deadlock is the following: > > > > a) the main thread calls MonitorExit in JavaCmdProc > > b) the garbage collection thread calls MonitorExit in JavaCmdDeleteProc > > c) the garbage collection thread calls MonitorEnter in JavaCmdDeleteProc > > > > d) the main thread calls MonitorEnter in JavaCmdProc (and blocks) > > > > I can think of two solutions to this problem, but I don't know which is > > "right." > > > > SOLUTION 1. Simply remove all remaining calls of MonitorEnter and > > MonitorExit. > > SOLUTION 2. Replace all remaining calls of MonitorEnter and MonitorExit > > by invocations of JAVA_LOCK and JAVA_UNLOCK, respectively (which now > > have the MonitorEnter and MonitorExit calls removed, but which retain > > the fiddling with the Java environment). > > > > In either case, we should possibly discover why Tclblend_Init is not > > being called, and fix that. > > > > What do you think? > > > > Thank you. > > > > > > 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 > > 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
