1. 26 Apr, 2016 1 commit
    • Allison Karlitskaya's avatar
      GContextSpecificGroup: detach sources · 62f320e6
      Allison Karlitskaya authored
      GContextSpecificGroup has been somewhat broken for a rather long time:
      when we remove the last reference on an object held in the group, we try
      to clean up the source, but fail to actually remove it from the
      mainloop.
      
      We will soon stop emitting signals on the source (due to it having been
      removed from the hash table) but any "in flight" signals will still be
      delivered on the source, which continues to exist.  This is a problem if
      the event is being delivered just as the object is being destroyed.
      
      This also means that we leave the source attached to the mainloop
      forever (and next time will create a new one)...
      
      This is demonstrated with the GtkAppChooser dialog which writes an
      update to the mimeapps.list file just as it is closing, triggering the
      app info monitor to fire just as it is being destroyed.
      
      Karl Tomlinson correctly analysed the problem and proposed this fix.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=762994
      62f320e6
  2. 13 Mar, 2015 1 commit
    • Allison Karlitskaya's avatar
      ContextSpecificGroup: some fixups · 0de16c98
      Allison Karlitskaya authored
      For all of the effort spent ensuring that this algorithm would be
      correctly threadsafe, I messed up the order of operations within a
      single thread when porting to the new approach.
      
      Fix that up.
      
      Also: fix some overzealous asserting in the testcases.  Since shutdown
      is now lazy, we can never surely say !is_running at any particular point
      in time.
      0de16c98
  3. 02 Mar, 2015 2 commits
    • Allison Karlitskaya's avatar
      GContextSpecificGroup: fix deadlock · 8c104a01
      Allison Karlitskaya authored
      There was a theoretical deadlock between the worker trying to emit a
      signal at the same time as we were waiting for it to shutdown the
      notification (while holding the lock).
      
      The deadlock was particularly annoying because we didn't really need to
      wait for the shutdown and because it wasn't possible to signals to
      arrive while waiting for a start.  Attempting to deal with start and
      stop in an asymmetric way could have lead to other weird situations,
      however.
      
      Drop the lock while waiting for the worker thread to start.  This means
      that we face the possibility of multiple waiters on the cond at the same
      time, so we need to make more of a state machine.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      8c104a01
    • Allison Karlitskaya's avatar
      Add internal helper GContextSpecificGroup · c90b083f
      Allison Karlitskaya authored
      Add a new internal helper called GContextSpecificGroup.
      
      This is a mechanism for helping to maintain a group of context-specific
      monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      c90b083f