<AWT Dev> deadlock between AppKit main thread and AWT event thread in JDK 17

[Philip Race]

Changing the name seems to have at least been useful to find cases such 
as this which I suspect are very, very rare.

 > My Java code sets up a secondary run loop.

But JDK only enters that mode if *it* creates a secondary run loop.

 >  The AppKit implementation of the file dialog calls Java to get 
accessibility information.

Why would Appkit call Java to ask about A11y info for a platform native 
dialog ?

I suppose the situation isn't as clear to me as it should be.

I might be asking a lot but is there a test case you can provide ?

As to making something like this part of a "public API" it seems to me 
that Java setting up this
mode in a 2ndary run loop in some situations is really an implementation 
choice and I wouldn't
know where to expose it even if it were something appropriate to do.
I'd sooner find a way to dispense with it entirely.
In fact there is some provision when doing FX interop to not use this 
mode at all.

-phil.


On 6/28/21 5:51 AM, Alan Snyder wrote:
> Hmm… it appears that in removing JavaNativeFoundation from the JDK the name of the run loop was changed from AWTRunLoopMode to javaRunLoopMode.
>
> If that is correct, it is an incompatible change that breaks third party use of JavaNativeFoundation for running code on the main thread.
>
> It also sounds like a gratuitous change.
>
>
>
>> On Jun 27, 2021, at 10:24 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>
>> I have a program that reliably deadlocks when run on JDK 17, but not on JDK 16 (although that may be due to timing differences, so it may not imply a new bug).
>>
>> It’s a fairly complicated situation.
>>
>> On the AWT thread, my program calls native code that displays a native file dialog. My Java code sets up a secondary run loop. The native code blocks on JNFRunLoop performOnMainThread to create the native file dialog.
>>
>> The AppKit implementation of the file dialog calls Java to get accessibility information. This sets up a run loop on the main thread and upcalls to Java. I presume this posts an AWT event.
>>
>> Before the AWT secondary run loop can process the request for accessibility information, it runs an invocation event (previously posted by a timer) that calls native code. This native code blocks attempting to perform code on the main thread using JNFRunLoop. Apparently, this request is never processed and the AWT thread remains blocked forever.
>>
>> If I change this latter native code to perform the main thread operation without blocking, there is no deadlock and all is fine.
>>
>> But I have encountered other deadlocks (not reliably repeatable) where this option is not available. Therefore, I would like to understand why this deadlock is happening.
>>
>> With run loops on both threads, what would cause the deadlock?
>>
>> [Question: does JDK 17 and JNFRunLoop use the same NSString to identify the java run loop mode? If not, might that matter?]
>>
>> I would appreciate any suggestions of what might be going wrong or how to track it down.
>>
>>   Alan
>>