On 19/01/2018 20:38, Krishna Addepalli wrote:
* <p> For example, requestFocus() generates native request, which
* generates one or two Java focus events, which then generate a
* serie of paint events, a serie of Java focus events, which then
* generate a serie of paint events which then are processed -
* three cycles, minimum. "
All I have done in the test case is to ensure that it runs consistently on all
types of machines and platforms.
As described above waitForIdle() may fail if there are kind of events
recursion. But this bug is different.
waitTillShown() also just sleeps for 100ms, which is not a guarantee that the
operation on the other thread has completed.
Hope this clarifies.
It does not guarantee but this wait + waitForIdle() should be enough.
Take a look to the code which generates the OPEN_EVENT used in the
fix(see Window.show()).
It is posted without relation to the native peer:
==========
1) EDT: Window.setVisible()->Window.show()->Window.postWindowEvent()->
barrier.await();
2) Main: blocked by barrier.await();
So your code waits when the setVisible() and some additional event
(OPEN_EVENT) will be dispatched by EDT.
==========
The usage of waitForIdle() should produce similar result:
1) EDT: Window.setVisible()->Window.show();
3) Main: post dummy event to EDT->waitLock.notifyAll();
2) Main: blocked in SunToolkit.waitForIdle(final long timeout) by
waitLock.wait();
The old code waits when the setVisible() and some additional event
(dummy) will be dispatched by EDT. But it also flush the native queue.
So it is still unclear why waitForIdle does not work.
Thanks,
Krishna
-----Original Message-----
From: Sergey Bylokhov
Sent: Saturday, January 20, 2018 5:20 AM
To: Krishna Addepalli <krishna.addepa...@oracle.com>; swing-dev@openjdk.java.net
Subject: Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to
java/awt/Paint/bug8024864.java
On 18/01/2018 19:39, Krishna Addepalli wrote:
Yes you are right, that waitForIdle() will make sure that all the events will
be processed on EDT. However, lets say the last event on the queue takes
sometime to process, then, syncNativeQueue could return true, since there are
no more events generated on the queue, and the waitForIdle could return.
For example, the event on the EDT could be waiting for a network operation to
complete, and till such time it might not generate any more events. But, there
is a high chance that, while it is waiting, that thread could get swapped by
another thread. If that thread tries to access the so called response from the
network immediately, it won't be able to get it, since the other thread has not
finished getting it.
Similarly, when there is a paint event, there is a small possibility that the
EDT thread might get swapped out before it could draw its contents to the
screen, and if the main thread accesses the screen immediately, it could get
wrong results. This is what would have happened in OEL, for this test case.
This situation should also be covered by the Toolkit.sync() which is called
inside waitForIdle(); Since this test additionally waits 100 ms in
waitTillShown() its is strange why waitForIdle() does not work.
--
Best regards, Sergey.
--
Best regards, Sergey.
