Hi, -XstartOnFirstThread is indeed only useful to SWT apps and OpenGL apps on macOS to my knowledge.
My need is either - to get the JVM able to start a Swing program without freezing when -XstartOnFirstThread is used. - OR to allow routing a java Runnable execution on the main macOS thread dynamically. Why do you think Swing could not be fix to be freely mixed with -XstartOnFirstThread? ------- Original Message ------- Le dimanche 19 mars 2023 à 01:58, Michael Hall <[email protected]> a écrit : >> On Mar 16, 2023, at 2:24 PM, Michael Hall <[email protected]> wrote: >> >>> On Mar 16, 2023, at 2:15 PM, Alan Snyder <[email protected]> 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:^(){ >> >> If it is and the block code is subsequently run without anything like the >> following >> >> if (async) >> [instance performSelectorOnMainThread:@selector(callback) withObject:nil >> waitUntilDone:NO]; >> else >> [instance performSelectorOnMainThread:@selector(callback) withObject:nil >> waitUntilDone:YES]; >> >> Then I am mistaken. >> >> I had sort of decided against testing this myself instead seeing if the main >> thread callback code I posted earlier would provide a workaround. >> >> But maybe I will still also test to see if already being on the main thread >> actually is or is not the problem. I’m not sure what other difference there >> would be on run on first thread? > > My best guess at this point after doing some testing is that the > -XrunOnFirstThread switch can’t be used with normal Swing apps. > > It requires a toolkit like Eclipse’s SWT to manage things this way. Seem > correct? If so might it merit a comment on the bug?
