Thanks for the suggestion
- Mike
(I have enclosed Jiang's msg below, for the non-HTML-groking emailers on this list)
At 12:48 PM 07/18/2000, Jiang Wu wrote:
You are correct that the code can block if Tcl thread A blocks on doing some work. To share a single thread amount multiple threads, the single thread can provide non-blocking operations. For example:
Tcl Thread A:
loop waiting for request from other Tcl threads {
* accepts the request with a notifier
* call into Java code along with the notifier
* Java code starts another Java worker thread
to do the work and returns immediately.
}
When the Java worker thread finishes, use the
notifier object to wake up anybody waiting.
Tcl Thread X:
* create a notifier
* send request to Tcl Thread A along with the notifier
* wait on the notifier
* gets the result
This mechanism uses multiple Java threads to do work in parallel. It also provides a blocking interface for Tcl Thread X. There are a number variation on this scheme depending on how you implement the notifier.
Of course, the problem is that the above is not part of TclBlend. If you are short on time, then you may need to find a different solution.
-- Jiang Wu
[EMAIL PROTECTED]
-----Original Message-----
From: Mike Schwartz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 18, 2000 11:19 AM
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: RE: [Tcl Java] tclBlend / tcl thread workaround
Jiang,
thanks for the response
You can do:
message passing on the event queue of A
...
I don't think this will work because the Java-side code can have one thread
block while waiting for another thread's work to complete. For example:
Tcl Thread C above will not be able to run because Tcl Thread B has tied up the single connection to the JVM, and Tcl Thread B needs C to complete. I.e., the system would deadlock.
Any other thoughts appreciated. At this point I'm about to give up on using TclBlend and rework my software to use a different approach that avoids the whole tclblend/tclthreading problem
- Mike
