Mo,
I did as you suggested (this is the first time I've run jdb, so I hope I am
using it to best advantage).
I have 7 Threads:
Thread-1 (running)
AWT-EventQueue-0 (cond. wait)
PostEventQueue-0 (cond. wait)
AWT-Windows (running)
IFC (cond. wait) (Yes, I am using IFC!)
TimerQueue(cond. wait)
interpreterworker (cond. wait)
Screen Updater(cond. wait)
Login eventing(cond. wait)
The thread that is blocked on the evt.sync() method is the Login eventing
thread.
From my reading of the Jacl source code, there is a test to see if this
thread (the "Login eventing" thread) is the primary thread for this
interpreter's notifier. Since it is not (it was created late in the game),
then - as I understand it - some other thread is supposed to be on the
other side of the event queue pulling off events.
Where is this thread? I guess that is where I am really confused.
My architecture is using a single interpreter and we send commands from a
GUI console-type source as well as hitting the interpreter from threads
that are "helper threads" for the IFC. That is -- The IFC thread responds
to the button press and create the "login event", it hands this off (via
proper synchronization) to the "Login eventing" threads, which then "fires"
the event into the Tcl system.
It is this "Login eventing" thread that is getting blocked.
Does this information help? Or should I do more research?
Thanks -- Randy
I can see the thread blocked on the evt.sync() call (outlined below)
At 02:48 PM 12/9/99 , Mo DeJong wrote:
Run this same code in Jacl under jdb. When it locks up, interupt
the code and see which threads are locked. You should then be able
to get a backtrace for each of the threads to find out where
the deadlock is. I think this bug in in the notifier somewhere, so
it should deadlock both Jacl and Tcl Blend.
Mo Dejong
Cygnus Solutions
On Thu, 9 Dec 1999, Randolph S. Kahle wrote:
I am making a lot of progress today understanding the JavaBean event
processing. But I am now stuck again.
In the class EventAdaptor.java the method _processEvent(...) has the
following code:
BeanEvent evt = new BeanEvent( interp, paramTypes, params, cmd );
interp.getNotifier().queueEvent( evt, TCL.QUEUE_TAIL);
evt.sync();
When my JavaBean fires an event into the Adapter class created by Tcl
(upon
registration using the java::bind command ), it locks up on the call to:
evt.sync();
(I put in trace print out).
and never returns.
What occurs to me is that there must be a Thread running on interp
somewhere that fetches these events and processes them internally. I do
not
have any such threads running. Can someone point me to the point where I
must be "spinning" a thread on the other side of this event queue?
I guess I'm missing a fundamental step here...
Thanks!
Randy Kahle
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]'.
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]'.
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]'.
