Re: [Qemu-devel] [Bug 1802684] Re: QEMU gui crashes on macOS Mojave

[Programmingkid <programmingkidx@gmail.com>]

> On Nov 11, 2018, at 6:55 AM, qemu-devel-request@nongnu.org wrote:
> 
> The code for the cocoa stuff is in ui/cocoa.m. Quick notes on structure:
> 
> * there is a weird thing where cocoa.m provides its own main(), and arranges that the function which is main() for every other UI is renamed qemu_main() and called later (I'd like to get rid of that one day if we could, it's just weird)
> * cocoa_display_init() is the "initialize the display" entry point -- this will always be called from on the main thread (strictly, from whichever thread OSX calls our applicationDidFinishLaunching callback on, but I assume that's the main thread)
> * the runtime entry points into the cocoa UI code are just the functions in the DisplayChangeListener struct: cocoa_update(), cocoa_switch() and cocoa_refresh()
> 
> Arranging for the last 3 to schedule their operation onto the main
> thread is probably what's needed. Things I don't know:
> 
> * should this "run thing on main thread" be synchronous or asynchronous? (sync is probably safest)
synchronous sounds good. 

> * what's the right OSX API to do this?
https://developer.apple.com/documentation/objectivec/nsobject/1414900-performselectoronmainthread?language=objc

> * how can we most cleanly do this in a way that still works on OSX 10.6 (the oldest we currently support)? (I suspect we'll need ifdefs and fall back to "just run on this thread" on older versions)

I would make another function called switchSurfaceInternal: and then move all the code from switchSurface: to this new function. Then have the switchSurface: method call the switchSurfaceInternal: method by using [performSelectorOnMainThread:withObject:waitUntilDone:]. 

The call would look like this: 
[self performSelectorOnMainThread: @selector(switchSurface:) withObject: surface waitUntilDone: YES]

I'm not sure if waitUntilDone should be set to YES. QEMU might work faster if it is set to NO. 

Thank you.