On Thu, 29 Nov 2018 at 02:11, berkus infinitus <ber...@gmail.com> wrote: > > I suspect the main problem is the blocking call to qemu_main > from the UI thread in the app delegate didFinishLoadingWithOptions > if i’m not mistaken and everything else grows from there.
Yes; if there's no way that Mojave will allow us to run qemu_main directly on the main thread, then we have to create a 2nd thread to run qemu_main on (which then becomes what QEMU thinks of as the "main loop thread"), and then we run into the need to make all the UI calls be forwarded from the main loop thread to the main thread, and to get QEMU locks when making calls into qemu from the main thread. I think the code we have in git currently will already do all the UI calls on the main thread -- it just does it by doing a blocking call into qemu_main which later does event processing itself. (It's a shame OSX doesn't document what you need to do to write code that way, it's a fairly common paradigm for other GUIs.) For High Sierra there is apparently a "main thread checker" utility: https://developer.apple.com/documentation/code_diagnostics/main_thread_checker so running DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib qemu-system-x86_64 args... will let us check for violations of the "do things on main thread" principle even without Mohave. For me with current QEMU it doesn't report any issues. thanks -- PMM