I've re-read the description of SequencedEvent and could not find any atomicity requirements. I mean, we can do it by either discarding events (as before) or by holding them for the future (as we do with out-of-order SequencedEvent events), but this would block the EDT and I'm not convinced 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 <mba...@redhat.com> wrote: > On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès < > bourges.laur...@gmail.com> 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 >>>> SequencedEvent could be a focus change event, and the subsequent events >>>> could be Key events. So, as per your solution, if we dispatch them, there >>>> is a possibility that the intended component may not receive those events. >>>> >>> My understanding is that if you want hard-dependency enforcements, you >>> have to wrap events under SequencedEvent events. All other asynchronous >>> events have absolutely no guarantees. Blocking the EDT should not be done >>> and that's the reason why we dispatch non-SequencedEvent events in the >>> meanwhile. Please note that the only events that are put on hold and >>> re-posted lated are SequencedEvent events that, if dispatched, would >>> violate the sequence rule. >>> >> >> I read again the patch code, and did not noticed what is causing other >> events go be dispatched instead of blocking. >> >> Could you explain your logic ? >> I jnderstand from Krishna comment that SequencedEvent induce a 'barrier' >> for related events... >> > > The EDT thread must not be blocked for longer periods -that is: discarding > or postponing the dispatch of incoming events-, because the whole > application gets unresponsive if we do so. Previous to this patch, the > filter in-place was discarding all the events except from SentEvent or > SequencedEvent events (depending on the revision) while waiting for > SequencedEvent events to be processed in the right order. > > What we do now is dispatching all asynchronous events (non-SequencedEvent) > while waiting for SequencedEvent events to be processed in the right order. > The rationale behind this decision is that there are no guarantees for > asynchronous events in regard to depending on SequencedEvent events. We are > just replacing a discard behavior with a dispatch anyways. > > Of course we comply with SequencedEvent order guarantees. If you need such > order guarantees on asynchronous events, you have to wrap any event in > SequencedEvent events. > > In my opinion, if an event depends on another and they are not both > wrapped in a SequencedEvent event, that's what is wrong. >
