On 9/14/2011 1:02 PM, Clemens Eisserer wrote:
Hi again,
If you are ok with the latest patch, could somebody please push it?
Yes, it looks fine. Printing the IllegalMonitorStateException into the
console seems acceptable for me: if application calls Thread.stop(), it
should be prepared to exceptions like this.
Would you prefer to push the fix into the awt-gate workspace yourself,
or you need any assistance with this?
Thanks,
Artem
Thanks, Clemens
2011/8/30 Clemens Eisserer <linuxhi...@gmail.com
<mailto:linuxhi...@gmail.com>>
Hi Artem,
I'm fine with EventDispatchThread.java changes from the full
version. Are the pushPopLock.__isHeldByCurrentThread() checks
required, given that EDT.interrupt() is now respected?
The checks avoid hanging in case Thread.stop() has been called,
without Thread.interrupt() before, as you stated:
What if somebody calls EDT.stop() directly, without preceding
interrupt()? I understand this is not a typical scenario, and we
probably shouldn't support it, but we should at least not hang.
I prepared another patch, which does not require those checks to
avoid hanging, however it will print out an
IllegalMonitorStateException in the case stop() has been called,
without interrupt() before:
http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.05/
<http://cr.openjdk.java.net/%7Eceisserer/7081670/webrev_full.05/>
The patch with the checks in is located at:
http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.03/
<http://cr.openjdk.java.net/%7Eceisserer/7081670/webrev_full.03/>
Once approved, the fix should go to JDK8 workspace first. Then
it will be backported to JDK7u.
Perfect :)
Caused by: java.lang.RuntimeException: Die, AWT-Event Queue
thread!
at HostileCrasher.<clinit>(LoopRobustness.java:157)
... 23 more
Exception in thread "main" java.lang.RuntimeException: Test
FAILED:
second thread hasn't notified MainThread
at LoopRobustness.main(LoopRobustness.java:70)
Hmm... That's odd. The test passes on my Windows desktop. The
first stack trace is printed to the console, but it's expected
as e.printStackTrace() is called from the test. However, the
second exception thrown from LoopRobustness.java:70 looks the
real problem.
Its basically the same problem, there is a fixed timeout (5s) but
sun.awt.SunToolkit.realSync waits for 10s and then times out.
If I increase the timeout to 60s I get the same Exception as with
the other test:
sun.awt.SunToolkit$OperationTimedOut: 10932
at sun.awt.X11.XToolkit.syncNativeQueue(XToolkit.java:2443)
at sun.awt.SunToolkit.realSync(SunToolkit.java:1580)
at sun.awt.SunToolkit.realSync(SunToolkit.java:1512)
at test.java.awt.regtesthelpers.Util.waitForIdle(Util.java:184)
at Impl.run(LoopRobustness.java:114)
at java.lang.Thread.run(Thread.java:722)
Thanks, Clemens
