You can do:
Tcl Thread A -> package require java -> start JVM ...
Tcl Thread B -> send request to Tcl thread A for Java work using
message passing on the event queue of A
Tcl Thread C -> send request to Tcl thread A for Java work ...
...
To share a single JVM using a critical section is not a good idea. This
critical section contains too much code. Critical section in general should
be used on a piece of very short execution code.
Many synchronization deadlocks arise because people make critical sections
too long and the code within the critical section too complex. For example,
Tcl thread A locks the JVM, then calls into the JVM to do some work using
Java thread A. Java thread B calls back into Tcl thread B for some data.
Tcl thread B blocks in trying to interact with Java thread B. At this
point, Java thread A may also block waiting for Java thread B to finish in
the JVM. The code deadlocks.
When sharing a long running piece of code, other forms of synchronization
work better such as locks and message passing. Tcl provides message passing
as the way to communicate between Tcl interpreter threads.
-- Jiang Wu
[EMAIL PROTECTED]
> -----Original Message-----
> From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 17, 2000 9:22 PM
> To: Mo DeJong; [EMAIL PROTECTED]
> Subject: [Tcl Java] tclBlend / tcl thread workaround
>
>
> so, I just had another idea:
>
> I don't really need (or even want) more than 1 JVM for all
> the tcl threads.
> On the Java side I have threads that allow concurrency among incoming
> requests, so the structure I really want is:
>
> - master tcl thread does 'package require java', which
> creates an instance
> of the JVM
> - all other threads that want to make JVM requests
> share that one instance,
> using appropriate synchronization around any
> critical section code
>
> Right now, the code that implements the 'package require
> java' command creates
> a new JVM per thread. What about implementing another
> tcljava command that
> lets me create one JVM and then share it among the tcl
> threads? That would
> workaround the current multithread/tclblend bug, and it would be more
> efficient (since otherwise I'm starting up the JVM every time
> a request
> comes in on the tcl side).
>
> Thoughts? Seems like this would be pretty easy to implement.
> - Mike
>
> ----------------------------------------------------------------
> 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
