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]'.
