<AWT Dev> OpenJdk11-28-EA JDialog hanging
mbalao at redhat.com
Wed Oct 17 16:05:54 UTC 2018
On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès <bourges.laurent at gmail.com>
>> 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
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...
More information about the awt-dev