Ok, approved
phil.
On 4/12/20, 4:05 AM, Sergey Bylokhov wrote:
Hi, Phil.
I completely forgot about that version of the fix, here are my
thoughts about it.
It does not fix the test in question, it is still executed too slow,
and fails by the
timeout, the reason is that it does not take into account the blocked
events when DnD
is active.
That version had two parts:
- The code which avoids the deadlock(actually it avoid an infinite
waiting):
http://cr.openjdk.java.net/~pchelko/9/7185258/webrev.01/src/macosx/native/sun/osxapp/NSApplicationAWT.m.sdiff.html
That was already fixed as part of JDK-8080504, and this is why I
cannot reproduce it now:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e06161762a72
- The part which tried to tweak the default timeout and had some code
to stop waiting:
http://cr.openjdk.java.net/~pchelko/9/7185258/webrev.01/src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java.sdiff.html
If I understand the code above correctly then on EDT it will wait
no more than 500 ms,
and in other cases will wait till the timeout, the same could be
achieved w/o the loop by the:
if (EventQueue.isDispatchThread()) {
// do not block EDT for a long time
timeout = XX;
}
return nativeSyncQueue(timeout);
I think that it could be useful to minimize blocking EDT, so decided
to merge this part to the current fix:
http://cr.openjdk.java.net/~serb/7185258/webrev.02/
On 4/7/20 3:04 pm, Philip Race wrote:
There were previous attempts to fix this on mac :
https://mail.openjdk.java.net/pipermail/awt-dev/2013-December/006719.html
https://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006809.html
https://mail.openjdk.java.net/pipermail/awt-dev/2014-February/007047.html
which you reviewed. Can you comment on how the current proposal avoids
the problems raised there ?
-phil.
On 4/6/20, 12:20 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk/client.
Bug: https://bugs.openjdk.java.net/browse/JDK-7185258
Fix: http://cr.openjdk.java.net/~serb/7185258/webrev.01
The Robot.waitForIdle and SunToolKit.realSync() may hang if executed
when DnD is
in progress, because they posts native events to the application and
waits when
these event will be dispatched. During DnD this events are blocked,
so every call
to waitForIdle will hang for a timeout(which is 10 seconds) per
native event check.
This may appear as a deadlock.
The similar bug was fixed on windows:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7658a78a93de
Solution on macOS is similar, skips the native checks when the DnD
is in progress.
