qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [RFC 0/5] ui/cocoa: Use OSX's main loop
@ 2018-12-01 12:30 Peter Maydell
  2018-12-01 12:30 ` [Qemu-devel] [RFC 1/5] ui/cocoa: Ensure we have the iothread lock when calling into QEMU Peter Maydell
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: Peter Maydell @ 2018-12-01 12:30 UTC (permalink / raw)
  To: qemu-devel
  Cc: patches, John Arbuckle, Berkus Decker, Gerd Hoffmann,
	Roman Bolshakov

This set of patches rearranges how we handle events on
the OSX Cocoa UI so that we use the main thread to run
the OSX event loop, and we don't do a long blocking
operation from the applicationDidFinishLaunching callback.
Instead we create a second thread which runs qemu_main()
and becomes the QEMU main-loop thread. The callbacks from
QEMU into the cocoa code asynchronously dispatch their
work to the main thread, and the main thread takes the
iothread lock before calling into QEMU code.

This code all works (though I have only smoke-tested it),
but it is marked RFC because it seems to be unclear whether
the current code in git master is really problematic for
Mojave. If it's not actually solving a problem then it's
a bit tricky to justify this rework, though it does mean
we're doing a less "weird" set of things and behaving a bit
more like how OSX expects apps to behave, so it might in
theory mean less chance of future breakage.

NB: the code to asynchronously run code blocks on the
main thread uses dispatch_get_main_queue(), which is a
10.10-or-later function. If we're going to go with this
refactoring I think the benefit in clarity-of-code is a
worthwhile gain for dropping support for ancient OSX versions.

Patchset structure:
 * patch 1 does the "make sure we have the iothread lock for
   calls into QEMU" (which is effectively a no-op initially
   since we'll already be holding that lock when our refresh
   etc callbacks are called)
 * patch 2 makes switchSurface directly take the pixman image
   (which is refcounted) rather than the DisplaySurface (which
   is not), so we can make the calls to it asynchronous later
 * patches 3 and 4 are just trivial code motion
 * patch 5 does the bulk of the work (and can't really be split
   further without the UI being broken at the intermediate point)

thanks
-- PMM

Peter Maydell (5):
  ui/cocoa: Ensure we have the iothread lock when calling into QEMU
  ui/cocoa: Use the pixman image directly in switchSurface
  ui/cocoa: Factor out initial menu creation
  ui/cocoa: Move console/device menu creation code up in file
  ui/cocoa: Perform UI operations only on the main thread

 ui/cocoa.m | 441 +++++++++++++++++++++++++++++++----------------------
 1 file changed, 258 insertions(+), 183 deletions(-)

-- 
2.19.2

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-12-05  6:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-12-01 12:30 [Qemu-devel] [RFC 0/5] ui/cocoa: Use OSX's main loop Peter Maydell
2018-12-01 12:30 ` [Qemu-devel] [RFC 1/5] ui/cocoa: Ensure we have the iothread lock when calling into QEMU Peter Maydell
2018-12-01 12:30 ` [Qemu-devel] [RFC 2/5] ui/cocoa: Use the pixman image directly in switchSurface Peter Maydell
2018-12-01 12:30 ` [Qemu-devel] [RFC 3/5] ui/cocoa: Factor out initial menu creation Peter Maydell
2018-12-01 12:30 ` [Qemu-devel] [RFC 4/5] ui/cocoa: Move console/device menu creation code up in file Peter Maydell
2018-12-01 12:30 ` [Qemu-devel] [RFC 5/5] ui/cocoa: Perform UI operations only on the main thread Peter Maydell
2018-12-03 15:47 ` [Qemu-devel] [RFC 0/5] ui/cocoa: Use OSX's main loop Richard Henderson
2018-12-05  6:51 ` Gerd Hoffmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).