[rfc] [icedtea-web] Fix EDT hanging on OpenJDK 11

[Martin Balao]

Hi Laurent,

On Thu, Sep 27, 2018 at 1:19 PM, Laurent Bourgès <bourges.laurent at gmail.com>
wrote:

> Mario,
>
> >     1. Why is EDT_DAEMON_THREAD_POOL needed?
>> >
>> >
>> > This is critical on OpenJDK 11 as SequencedEvent processing is buggy
>> > (still not fixed).
>> > - This specific Thread pool uses a specific factory to create threads in
>> > main thread group (main thread).
>> >
>> >     public Thread newThread(Runnable r) {
>> >             final Thread t = new Thread(MAIN_GROUP, r, ...
>> > - Such particular thread then calls SwingUtilities.invokeXxx() methods,
>> > making EDT/AWT use the proper main AppContext & EventQueue.
>> >
>> >     EDT_DAEMON_THREAD_POOL.submit(new Runnable() {
>> >                 public void run() {
>> >                     SwingUtilities.invokeLater(doRun);
>> >                 }
>> >             });
>> >
>> > This pattern allows to transfer any Swing / AWT invocations from any
>> > running Thread (in or out the main Thread group) into the proper
>> > AppContext, like a "priviledged" ITW GUI action.
>>
>> Yeah, but it's still ending up in the EDT, I'm puzzled as to what is
>> different here than directly using invokeAndWait/invokeLater.
>>
>
> It is related to Swing/Awt internals that associate awt.AppContext to one
> ThreadGroup:
> in ITW, several thread groups are in use (application, security, main ...)
> so each thread group can have its own awt.AppContext, EventQueue and
> EventDispatcherThread as a consequence.
>

What would be the use-case that requires this "bridge"?

I suggest to revert this part of the changeset and further discuss it. In
case that something were broken by reverting only this part, I suggest to
put the whole patch on hold.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20181003/928f367e/attachment.html>