<AWT Dev> OpenJdk11-28-EA JDialog hanging

[Martin Balao]

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 <mbalao at redhat.com> wrote:

> On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès <
> bourges.laurent at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20181017/b6da6133/attachment-0001.html>