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

[Programmingkid]

> On Nov 11, 2018, at 6:55 AM, address@hidden 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.