On 27/05/2011 15:37, Walter Laan wrote:
We didn't change JComponent.repaint() to make it "no longer thread
safe"
and I don't see why someone may think about it
The bug report https://netbeans.org/bugzilla/show_bug.cgi?id=192548
shows the stack:
-
With the latest changes to jdk7 and jdk6 update 22 it's no longer true
due to
repaint()'s call to getLocationOnScreen() which acquires AWT tree lock:
Whilst not ideal, it doesn't seem unreasonable that repaint should
acquire a lock (that's usually how thread-safety is done).
The stack trace in that bug doesn't appear to show a deadlock as such.
What it does show is Netbean waiting on one of its own locks on the AWT EDT.
"AWT-EventQueue-0" prio=6 tid=0x04713c00 nid=0x7d8 in Object.wait()
[0x0599e000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x1c24efb0> (a
org.netbeans.lib.editor.util.PriorityMutex)
Tom (not in AWT/Swing)
