> On Mar 20, 2023, at 2:12 PM, Sergey Bylokhov <[email protected]> wrote:
>
> On 3/16/23 12:15, Alan Snyder wrote:
>> The test for already being on the main thread should be performed in one
>> place, in this method:
>>> On Mar 16, 2023, at 6:07 AM, Michael Hall <[email protected]> wrote:
>>>
>>> [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>
> That check is already there:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m#L103
>
> --
> Best regards, Sergey.
>
Yes I had found that. That is still where it hangs. Without the
-XrunOnFirstThread the block runs. With it the code hangs. I put NSLog’s into
the code.
SHIFT+CTRL+\ for stack trace on bug report test case shows where.
After seeing this (java_md_macosx.m JVMInit sameThread is true)…
/*
* We cannot use dispatch_sync here, because it blocks the main
dispatch queue.
* Using the main NSRunLoop allows the dispatch queue to run
properly once
* SWT (or whatever toolkit this is needed for) kicks off it's own
NSRunLoop
* and starts running.
*/
I would think the problem is that -XrunOnFirstThread is intended for ’toolkit’s
that aren’t Swing based but handle the gui and NSRunLoop as indicated
themselves - like Eclipse with SWT.
Arbitrary Swing app’s just can’t use this jvm switch.
And weren’t meant to?
