<AWT Dev> OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Sergey,

On Thu, Oct 18, 2018 at 3:35 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> wrote:

> On 17/10/2018 07:12, Martin Balao wrote:
>
>> Have you tried Laurent's test case on Mac? (the version previous to my
>> refactorings, so we eliminate the OS layer). This bug should manifest there
>> too. Unfortunately, I don't have such environment to test and debug.
>>
>
> Yes, it is not reproduced on macos, at-least not so easy like on win/lin.
>

I should have said, the first version of Laurent's test [1]. Perhaps some
tweaks are still needed; we need a test that artificially injects the
events and does not depend on the OS UI subsystem. But the problem should
be there too.


>
>     __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.
>>
>
> An explanation of SequencedEvent above is correct, we need to block the
> thread until another SequencedEvent will be dispatched or for some reason
> will be dropped. This is a functional which allow synchronize execution
> between different EDT(per Appcontex). This is a rare case, which mostly
> related to the "focus" functionality, because the java can have only one
> focused element at a time, and we need to manage it between different
> applications inside jvm. One application is webstart itself and another is
> the user's application.


I'll give an example to further illustrate. Let's suppose that we inject a
sequence of 3 windows focus events on different app contexts and 1
keystroke in-between. We will wrap each windows focus event on a
SequencedEvent event -so there is a specific order that has to be honored-
and the keystroke event will not be wrapped. Previous to the proposed
patch, the keystroke event would have been discarded while the EDT is
blocked on the filter -waiting for other SequencedEvent events to be
dispatched before-. With the proposed patch, the keystroke is considered an
asynchronous event (not part of the sequence, not wrapped in a
SequencedEvent) and is dispatched when it comes. My understanding is that
if we want the keystroke to be part of the sequence (synchronized), it has
to be wrapped with a SequencedEvent.

Having said that, I'll further investigate what are the assumptions clients
are having, which events are wrapped on SequencedEvent events and which are
not. At this point, I'm not completely sure if hardware generated events
like keystrokes are wrapped or not.

Going back to Krishna's comment, my understanding is that the Key event
(assuming it's a non-SequencedEvent event) would have been lost previous to
this change if the EDT is blocked waiting for a SequencedEvent event.


>
> 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.
>>
>
> It is still unclear what is going wrong, based on the stack trace it is
> clear that a few SequencedEvent waits each other, but why the last(or
> first) SequencedEvent, which should flush this queue, was not dispatched?
> Is it possible that this event was dropped for some reason, like its source
> was disposed, the appcontext itself was disposed, any other reasons?
>
>
What is going wrong where? Which stack trace do you mean?

Kind regards,
Martin.-

--
[1] -
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20181018/35a16f47/attachment-0001.html>