Even though I'm still not convinced about the need of imposing partial order sync on asynchronous events, we can do it.
Here it's Webrev.03 that includes partial ordering of non-SequencedEvent events and Sergey's unit test: * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03/ * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03.zip I've put Sergey's unit test into a bash-loop and reached 300+ iterations without any issues. Laurent's functional test is also passing. Laurent's unit test (not included here) does not pass for the reasons already discussed. Kind regards, Martin.- On Wed, Oct 31, 2018 at 1:13 PM, Sergey Bylokhov <sergey.bylok...@oracle.com > 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: >> >> * dispatchSENumber < num1 >> * dispatchSENumber < num2 >> >> My understanding is that these assertions mean that a non-SequencedEvent >> event is expected to be synchronized with SequencedEvent events. If such >> synchronization is needed, the event has to be wrapped in a SequencedEvent >> event. There are no guarantees otherwise; previous to my proposal these >> event were discarded and in my Webrev.02 they are dispatched asynchronously. >> > > This is not a strong synchronization, it is just an expectation that the > events which were posted after SequencedEvent should be dispatched after > it. So if the app will have focus event and then mouse click, then mouse > click should be dispatched after the focus. Note that the for this case the > test does not check the exact sequence of order(==), just a relative > order(<). > > > -- > Best regards, Sergey. >
