Thank you all, good conclusion to JDK users, :) At 2011-05-28 01:40:28，"Anthony Petrov" <[email protected]> wrote:
>On 5/27/2011 7:33 PM, [email protected] wrote: >> 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) > >Thanks Tom. That's a nice find. > >I'm not sure if this is documented somewhere (if not, it should be), but >while being multi-threaded, AWT doesn't tolerate blocking of the EDT >under any circumstances. It's a general understanding/agreement that >events must be processed as fast as possible. Moreover, this is >especially relevant to Swing since most of Swing operations should take >place on the EDT *only*, and as such keeping the thread unblocked is >vital for Swing to operate correctly. The library even provides the >SwingWorker utility class that helps process long operations while >allowing the EDT to handle other events. > >The only allowed case when the EDT can be blocked is displaying a modal >(J)Dialog by means of calling its setVisible(true) from an event >handler. In this case AWT/Swing are responsible for keeping the wheel >rolling. In all other cases a blocked EDT may cause problems that >AWT/Swing simply can't resolve. > >So, if the deadlock (or whatever it is) is caused by blocking the EDT, >this suggests that it is NetBeans that's causing the problem, not JDK. > >-- >best regards, >Anthony
