Hi,
Submit-repo tests passed.
Changeset has been committed:
http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
Thanks to all of you for your time reviewing this.
I'll now propose a JDK-11 backport.
Kind regards,
Martin.-
nov. 2018 à 14:50, Laurent Bourgès a
> écrit :
>>
>> Dear Martin & Sergey,
>>
>> I just tested webrev.03 on latest openjdk12 and it passed my tests: good
>> job !
>> (I am not an official openjdk reviewer)
>>
>> Le ven. 9 nov. 2018 à 14:43, M
On Fri, Nov 9, 2018 at 10:50 AM, Laurent Bourgès
wrote:
>
> I suppose the Webrev.04 only removed the SequencedEventTest class ?
>
That's right
Hi,
Here we have Webrev.04:
* http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
* http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip
@Sergey: are you okay to go?
Thanks,
Martin.-
On Thu, Nov 8, 2018 at 9:09 PM, Sergey Bylokhov
wrote:
> I am fine wit
Hi Sergey,
What the test is doing does not look right to me.
An event whose source app context is associated with "system" thread
group is being posted on the EventQueue of an app context associated
to "TestThreadGroup" thread group. See
"Toolkit.getDefaultToolkit().getSystemEventQueue().postEven
es not pass for the reasons already
discussed.
Kind regards,
Martin.-
On Wed, Oct 31, 2018 at 1:13 PM, Sergey Bylokhov wrote:
> Hi, Martin.
> On 31/10/2018 09:03, Martin Balao wrote:
>
>> Your MultipleContextsUnitTest test has 2 assertions that don't look good
>> to me:
>
e:
> http://cr.openjdk.java.net/~serb/8204142/webrev.00/
>
> But I have run it for a night in a bash loop, and it failed after 100+
> iterations. So there is some room for improvements.
>
> Note that this fix should be applied on top of JDK-8211435:
> http://cr.openjdk.java.net
Hi,
Digging a bit into SequencedEvent event clients, I've found 3 usages:
1) Wrapping focus in and out window events (Unix only)
2) Wrapping TimedWindowEvent events (Windows and macOS only)
3) Wrapping FocusEvent events in
XEmbedChildProxyPeer.simulateMotifRequestFocus (Unix only)
This is how
On Fri, Oct 26, 2018 at 6:59 PM, Sergey Bylokhov wrote:
> On 25/10/2018 01:05, Laurent Bourgès wrote:
>
>> According to me, Martin already exposed his detailled analysis of 2 cases
>> making AWT to hang with several AppContexts: in summary, like a deadlock,
>> the EDT threads are waiting for each
Yes, I think we now have a good understanding of why this hangs.
The remaining discussion, in my opinion, is if we should block or not while
handling SequencedEvents. I'd like to see strong arguments on both sides to
get this right. Even though my original position was for not-blocking -for
the re
> To conclude, I tried adopting a more conservative approach in my last
> hack, but I needed dispatching InvocationEvents to let swing.Timer continue
> to work.
> I do not know if it is better to select which events to accept (while
> list) or to select which events not reject (black
Yes, your results are exactly what I was expecting.
On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès
wrote:
> Hi Martin,
>
> Here are my test outputs:
>
> 1/ First
> $ java TestWinEvent
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.RepaintManager$
On Thu, Oct 18, 2018 at 3:58 PM, Laurent Bourgès
wrote:
> Hi Martin,
>
> PS: could you tell me what lines to change to discard non sequenced events
>>> in your patch ? I will then try it
>>>
>>
>> Instead of "if (ev.getID() == ID) { ... } return FilterAction.ACCEPT;",
>> do:
>>
>> "if (ev.getID()
On Thu, Oct 18, 2018 at 12:14 PM, Laurent Bourgès wrote:
>
>
> PS: could you tell me what lines to change to discard non sequenced events
> in your patch ? I will then try it
>
>
Instead of "if (ev.getID() == ID) { ... } return FilterAction.ACCEPT;", do:
"if (ev.getID() == ID) { ... } else if (e
On Thu, Oct 18, 2018 at 11:05 AM, Laurent Bourgès wrote:
>
>
> There is no shame that EDT or event processing consuming lots of cpu
> cycles, in such intensive tests.
>
>
That's not a problem, the problem is starvation of
non-SequencedEvent events if the EDT is blocked-like rejecting them all.
Eve
Hi Sergey,
On Thu, Oct 18, 2018 at 3:35 AM, Sergey Bylokhov wrote:
> On 17/10/2018 07:12, Martin Balao wrote:
>
>> Have you tried Laurent's test case on Mac? (the version previous to my
>> refactorings, so we eliminate the OS layer). This bug should manifest there
>>
Hi Laurent,
On Wed, Oct 17, 2018 at 8:13 PM, Laurent Bourgès
wrote:
>
> If the behavior changed in your patch, it sounds more conservative to
> discard events (as before) if the present bug is still fixed.
> It could be revisited later in another appropriate bug.
> Is it a trivial change in your
nced
to do so.
BTW: this may explain the "null windows source" error we noticed with
Laurent under the test stress conditions.
On Wed, Oct 17, 2018 at 6:05 PM, Martin Balao wrote:
> On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès <
> bourges.laur...@gmail.com> wrote:
>
On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès
wrote:
> Martin,
>
>> 2. I’m not sure if I agree to your proposal of dispatching
>>> non-SequencedEvents, from the queue. The events arriving after a particular
>>> SequencedEvent could be dependent on this event – for example, the current
>>
Hi Krishna,
On Wed, Oct 17, 2018 at 3:51 PM, Krishna Addepalli <
krishna.addepa...@oracle.com> wrote:
>
> 1. This problem (including the one described in JDK-8152974) is not
> reproducible at all in Mac. I would like to understand why this happens
> only on Windows/Linux because the proposed
Hi Laurent,
Thanks for your test! Great job :-)
I applied some minor changes for integration:
* Renamed to TestSeqEventsMultipleContexts
* A bit longer but should describe what this is about
* Placed in jdk/java/awt/event/SequencedEvent
* Encapsulated the window in TestWindow class
* In
Hi Laurent,
Thanks for your feedback and happy to hear that it worked!
In regards to pendingEvents sync, my understanding is that SequencedEvent
objects will be posted to one EventQueue only and, thus, be dispatched by
one EDT.
I had a quick look at "Exception in thread "AWT-EventQueue-1"
java.l
Hi Laurent,
Thanks for your feedback and sharing your test.
I've taken your suggestion of making the filter class final. In regards to
having a single instance of the filter class, it would have been a good
idea but now we have some additional requirements you'll see below.
I could reproduce you
Hi,
Can I have a review for JDK-8204142 [1] Webrev 00?
* http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00/
* http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00.zip
As a result of [2], I propose Event Dispatch Threads to be aware of
SentEvent AWT events whe
Hi all,
I was not sure if my runs of SequencedEventTest test were triggering the
problematic execution flow, because this issue should manifest even after
JDK-8152974 [1] fix. After a few tries I attached a debugger. Attaching a
debugger obviously interferred with robot steps on the test but, anyw
25 matches
Mail list logo
