<AWT Dev> OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin,

Le mer. 17 oct. 2018 à 18:33, Martin Balao <mbalao at redhat.com> a écrit :

> 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.
>

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 event filter ? I am looking forward trying
this alternative sllution.


> BTW: this may explain the "null windows source" error we noticed with
> Laurent under the test stress conditions.
>

I am understanding now why this side effect happened few times in my tests.

Thanks,
Laurent

>
> 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/57575222/attachment.html>