Re: deadlock between AppKit main thread and AWT event thread in JDK 17

> On Jul 8, 2021, at 5:18 PM, Philip Race wrote: > > There has never been any contract that JDK would use JNF or specify a value > for a run loop. > I'd be interested to know where this was documented. I can't even find any > Apple docs. > There's no way we would ever consider something

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

The only thing that needs to be part of the API is the run loop mode *name*. If for some reason in the future the JDK stops using a native run loop when the AppKit main thread calls Java, there is no harm if a native (JNI) library calls performOnMainThread and passes that name as one of the run

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

There has never been any contract that JDK would use JNF or specify a value for a run loop. I'd be interested to know where this was documented. I can't even find any Apple docs. There's no way we would ever consider something like this name a supported interface without lots of thought and

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

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

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

To avoid this deadlock, the run loop name is required when using the NSObject method performSelectorOnMainThread:withObject:waitUntilDone:modes: JNF calls this method with the “old” run loop

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

> On Jun 28, 2021, at 9:50 AM, Alan Snyder wrote: > > To avoid this deadlock, the run loop name is required when using the NSObject > method performSelectorOnMainThread:withObject:waitUntilDone:modes: >

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

My code (#2) running on the AWT thread is blocked trying to perform selector on main thread waiting YES. It is blocked because it does not specify that it can be run under the javaRunLoopMode. It specifies the AWTRunLoopMode, which is the old name. That name is supplied by JavaNativeFoundation.

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

> On Jun 28, 2021, at 9:30 AM, Alan Snyder wrote: > > My code (#2) running on the AWT thread is blocked trying to perform selector > on main thread waiting YES. It is blocked because it does not specify that it > can be run under the javaRunLoopMode. It specifies the AWTRunLoopMode, which

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

> On Jun 28, 2021, at 9:03 AM, Alan Snyder wrote: > > You can call performSelectorOnMainThread directly, but you have to know the > name of the AWT/Java run loop to avoid the deadlock situations that I have > encountered. > > The name of the run loop needs to be part of the public API. I

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

You can call performSelectorOnMainThread directly, but you have to know the name of the AWT/Java run loop to avoid the deadlock situations that I have encountered. The name of the run loop needs to be part of the public API. By the way, upcalls from AppKit to get accessibility information has

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

> On Jun 28, 2021, at 7: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

Re: deadlock between AppKit main thread and AWT event thread in JDK 17

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

deadlock between AppKit main thread and AWT event thread in JDK 17

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