The documentation on tcljava is pretty good but unfortunately I still can't see exactly how/if tcljava can help me. The question is probably a stupid one but here goes anyway.
I have an existing C application that allows implementors to customise/extend its behaviour via embedded tcl Interpreters which evaluate scripts at various well-defined points/triggers.
To achieve this a number of application-specific tcl extensions are provided that allow access to and manipulation of the application's data from within the tcl script.
So the relationship between me and an implementor is
MyApplication-->YourTclscript-->MyExtension
I'd like to be able to provide implementors with the option of using Java to achieve a similar degree of control.
To avoid unnecessary changes to the C application the logical model for a Java implementor seems to be
MyApplication-->Tcl_To_JavaWrapper-->YourJava-->Java_To_Tcl_Wrapper-->MyExtension
It seems that the "Tcl_To_JavaWrapper" should consist of a java class invoked by a tcl script that uses
"java:getinterp"
and then
"java::new" with the interpreter handle as an argument
and that this way I can maintain a reference to the correct embedded tcl interpreter to utilise in the "Java_To_Tcl_Wrapper" with a call on "eval".
Could some kind person confirm if this is this in fact correct and an appropriate way to use tclblend?
Secondly I have noticed a large volume of correspondence regarding threading issues, but not really followed it closely. My C application is multi-threaded, each thread creating its own tcl interpreter. It seems that the intention (in the version of tclblend I downloaded sometime ago - 1.25) is that all threads in the process will share a single JVM. My application will already protect against any race conditions during thread creation. Are there any isssues here that are going to bite me?
Thanks in advance for your help.
Pete
Disclaimer
This email is confidential and intended solely for the use of the individual
to whom it is addressed. Any views or opinions presented are solely those
of the author and do not necessarily represent those of Trace Computers PLC.
If you are not the intended recipient, be advised that you have received
this email in error and that any use, dissemination, forwarding, printing,
or copying of this mail is strictly prohibited
