Skip to content
Snippets Groups Projects
  1. Mar 28, 2022
  2. Mar 21, 2022
  3. Mar 18, 2022
  4. Mar 15, 2022
  5. Mar 14, 2022
  6. Mar 07, 2022
  7. Mar 04, 2022
  8. Mar 02, 2022
    • Peter Maydell's avatar
      ui/cocoa.m: Remove unnecessary NSAutoreleasePools · 268c1198
      Peter Maydell authored
      
      In commit 6e657e64 in 2013 we added some autorelease pools to
      deal with complaints from macOS when we made calls into Cocoa from
      threads that didn't have automatically created autorelease pools.
      Later on, macOS got stricter about forbidding cross-thread Cocoa
      calls, and in commit 5588840f we restructured the code to
      avoid them.  This left the autorelease pool creation in several
      functions without any purpose; delete it.
      
      We still need the pool in cocoa_refresh() for the clipboard related
      code which is called directly there.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Tested-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Message-id: 20220224101330.967429-3-peter.maydell@linaro.org
      268c1198
    • Peter Maydell's avatar
      ui/cocoa.m: Fix updateUIInfo threading issues · 8d65dee2
      Peter Maydell authored
      
      The updateUIInfo method makes Cocoa API calls.  It also calls back
      into QEMU functions like dpy_set_ui_info().  To do this safely, we
      need to follow two rules:
       * Cocoa API calls are made on the Cocoa UI thread
       * When calling back into QEMU we must hold the iothread lock
      
      Fix the places where we got this wrong, by taking the iothread lock
      while executing updateUIInfo, and moving the call in cocoa_switch()
      inside the dispatch_async block.
      
      Some of the Cocoa UI methods which call updateUIInfo are invoked as
      part of the initial application startup, while we're still doing the
      little cross-thread dance described in the comment just above
      call_qemu_main().  This meant they were calling back into the QEMU UI
      layer before we'd actually finished initializing our display and
      registered the DisplayChangeListener, which isn't really valid.  Once
      updateUIInfo takes the iothread lock, we no longer get away with
      this, because during this startup phase the iothread lock is held by
      the QEMU main-loop thread which is waiting for us to finish our
      display initialization.  So we must suppress updateUIInfo until
      applicationDidFinishLaunching allows the QEMU main-loop thread to
      continue.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Tested-by: default avatarAkihiko Odaki <akihiko.odaki@gmail.com>
      Message-id: 20220224101330.967429-2-peter.maydell@linaro.org
      8d65dee2
  9. Feb 21, 2022
  10. Jan 18, 2022
  11. Jan 13, 2022
Loading