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.
--
Best regards, Sergey.
