[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-swing-dev
Subject:    Re: <Swing Dev> [11][JDK-8176512][TEST_BUG] add a minimal delay to java/awt/Paint/bug8024864.java
From:       Sergey Bylokhov <Sergey.Bylokhov () oracle ! com>
Date:       2018-02-05 20:14:55
Message-ID: a2fd2844-c32c-2e33-7fbc-7ff4c5d40842 () oracle ! com
[Download RAW message or body]

On 05/02/2018 10:15, Krishna Addepalli wrote:
> "Because it will flush the native queue a few times, then flush EDT, and then it \
> will wait 100 ms(minimum)." In my opinion, flushing will only push the events to \
> the queue, but will not guarantee that the last event pushed has been executed on \
> EDT. Also, the wait for 100ms seems arbitrary. I mean, it cannot be universally \
> reasoned that it will work on all systems.

No should be guarantied, because dummy event will be the last event 
pushed to EDT, and when this dummy event will be dispatched by the EDT 
it will unlock the main thread. So for example if in the queue we will 
have a few events which should be dispatched and waitForIdle will post 
dummy event, then waitForIdle will wait until all events in the 
EventQueue will be dispatched by EDT.

> "If it is incorrect then why do you need to wait when OPEN_EVENT will be dispatched \
> at all, since you mention that "super.show()" call which ultimately leads to \
> AwtComponent::_Show function". So AwtComponent::_Show will be called before the end \
> of Window.show()." This is because EDT and main thread are different. EDT can get \
> swapped by Main thread right after the show() call, but before EDT had a chance to \
> draw something on the screen. Although this happens rarely, it cannot be ruled out. \
> > "My point is that the fix and previous implementation is mostly identical. And if \
> > old implementation does not work then it is a bug somewhere in the robot."
> I feel this problem arises because of the complex interaction between Main thread \
> and EDT, which can be hard to debug. Anyway, I agree that we need to investigate \
> this, but I guess we should fix it in a separate bug.

In some cases yes, but if we have a testcase which can reproduce the bug 
in product we should not fix the test case. Especially if the fix 
implements the similar logic which does not work in product.


-- 
Best regards, Sergey.


[prev in list] [next in list] [prev in thread] [next in thread]