On Fri, 23 Feb 2024 17:39:44 GMT, Kevin Rushforth <k...@openjdk.org> wrote:

> This changes one of the fundamental aspects of entering and exiting a nested 
> event loop. This will need a lot more analysis to show why this is the right 
> approach.

Yes, this is right and I also thought about documenting that as soon as we 
think that this is the right approach.
I completely agree that we need to analyse this. This is not a simple change 
but will affect Dialogs and every custom code that uses nested event loops 
(e.g. I used it for blocking the UI without freezing it for data loading 
purposes, where we want to wait until the code returns in a non UI blicking 
way).

Maybe there is a better way as well, I just don't figured out one. 
As described, right now we rely that `enterNestedEventLoop` returns always, 
which is not happening immediately for ALL platforms, even though Platform has 
another implementation. Which makes me think the current approach has a flaw, 
resulting in this behaviour.

> I see the same failure with the most recent patch as I did yesterday. I 
> looked over the changes, and I'm not convinced that this is the right 
> approach.

Thanks for testing. As soon as my colleague is available, I will debug this 
issue. I don't get why only MacOS is failing, since the low level code is 
pretty much the same, we just continue right after we left the nested event 
loop.
I agree that we should find out the root cause why MacOS behaves different.

> I don't know of any supported way to run macOS in a VM on a Windows host, but 
> perhaps others will be able to help.

That was also my understanding the last time I checked. AFAIK, think there is 
no official way from Apple, but VirtualBox may offer that. Will check as soon 
as I have more time.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1324#issuecomment-1962428672

Reply via email to