This is more of an FYI than specific help for this problem.
The InvokeLater function is intended for running quick UI related
methods which should never be holding a lock when passed to
InvokeLater. Since these are run during the event thread that updates
all the UI components, doing otherwise will result in a poor user
experience. There used to be a "long" list of component methods that
could only be called as part of the event thread.
You may wish to have some utility thread(s) that can perform these
functions instead of using InvokeLater.
You can use ctl break on Windows to force the JVM to print out the
current stack of each thread. If threads are deadlocked, the JVM will
indicate that and what they are deadlocked waiting for. On Unix you
can use the kill command. The dump looks just like below in this
mmessage. http://java.sun.com/developer/onlineTraining/Programming/JDCBook/stack.html
At 1:39 PM -0600 8/15/05, Doug Zwick wrote:
We're now seeing a deadlock in our Swing application. We have
recently made a change to do
more of our startup process on the Swing thread, so that Swing
component updates will be
performed from the Swing thread. We do this using a Runnable passed in to
SwingUtilities.invokeLater. We wind up queuing a number of tasks.
What is alarming is that
MRJ 2.2 seems to allow two of these runnables to execute at once,
from different threads,
which leads to the deadlock we are seeing.
The Runnable being run by AWT-EventQueue-0 is started first. It gets
and holds the monitor that
the second Runnable (being run by AWT-Dispatch-Proxy) is waiting
for. AWT-EventQueue-0 is in the
process of posting a modal dialog. When the dialog is showing I
would expect to see a nested AWT
event loop on the stack of AWT-EventQueue-0, that in turn would
process Runnables queued using
SwingUtilities.invokeLater.
I suspect that VFramePeer is depending on AWT-Dispatch-Proxy to make
the peer visible, but it
can't because it is blocked waiting for the monitor. If the one
being run by AWT-Dispatch-Proxy
had been run from AWT-EventQueue-0, there would be no deadlock
(although the assumptions of the
calling thread that no other thread-of-execution will be able to
muck with the object locked by
the held monitor may well be invalidated).
Can anyone shed any light on what the "AWT-Dispatch-Proxy" thread is
supposed to be doing, and
why it is servicing the main event queue? Could this be a feature of
the AWT event loop to keep
logically distinct threads-of-execution that may be executing on the
same Thread from munging
data under a locked monitor?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
