1. 07 Nov, 2017 1 commit
  2. 08 Sep, 2017 1 commit
  3. 29 May, 2017 1 commit
  4. 22 Nov, 2016 1 commit
  5. 14 Mar, 2014 2 commits
    • Allison Karlitskaya's avatar
      GSettingsBackend: fix a nasty race condition · 3f119b2f
      Allison Karlitskaya authored
      In the event that a GSettings object is being destroyed just as a change
      signal is being delivered, the destroying thread will race with the
      dconf worker thread for acquiring the lock on the GSettingsBackend.
      If the signalling thread gets there first then the destroying thread
      will block on the lock.  The signalling thread adds a reference to the
      GSettings object that is being destroyed and releases the lock.  The
      idea is that this should prevent the GSettings object from being
      destroyed and thus maintain its entry in the list.  Unfortunately, the
      weak reference notify function is already running and as soon as we
      release the lock, the list entry is removed.
      The signalling thread crashes.
      This bug is indicative of a serious problem encountered in many
      situations where GObject instances are touched from multiple threads.
      Ideally, we will move to a place where g_object_ref() is not called at
      all on the GSettings object from the dconf worker thread and instead, a
      dispatch will be done without holding a reference (similar to how
      GAppInfoMonitor presently works).  This would also prevent the
      unfortunate case of someone dropping what they assume to be the last
      reference on a GSettings object, only to have an already-pending signal
      delivered once they return to the mainloop, crashing their program.
      Making this change for GSettings (with multiple instances per thread,
      the possibility of multiple backends and each instance being interested
      in different events) is going to be extremely non-trivial, so it's not a
      change that makes sense at this point in the cycle.
      For now, we can do a relatively small and isolated tweak so that we
      never access the list except under a lock.  We still perform the bad
      pattern of acquiring a ref in a foreign thread which means that we still
      risk delivering a signal to a GSettings object that the user has assumed
      is dead (unless they explicitly disconnect their signal handler).  This
      is a problem that we already had, however.
    • Allison Karlitskaya's avatar
      gsettingsbackend: a minor simplification · 698970f1
      Allison Karlitskaya authored
      Change the order of the arguments on the (internal) keys_changed callback in
      This means that all functions in the table now fit the following signature:
        void (* f) (GObject             *target,
                    GSettingsBackend    *backend,
                    const gchar         *name_or_path,
                    gpointer             origin_tag,
                    const gchar * const *names);
      allowing the possibility of arguments ignored at the end.
      This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
      making it a bit less generic.
      So far, this should be a straight refactor.
  6. 06 Feb, 2014 2 commits
  7. 31 Jan, 2014 2 commits
  8. 01 Jan, 2014 1 commit
  9. 28 Oct, 2013 1 commit
    • Allison Karlitskaya's avatar
      GSettingsBackend: add read_user_value() API · 84a6e651
      Allison Karlitskaya authored
      This will get the 'user' value from the database (ie: the one that the user has
      control over).
      Provide a default implementation that chains to ->read().  That will work for
      all of our internal backends which don't have a concept of layering or
      The delayed backend implments "user value" by returning anything that's
      in the changeset (incuding an explicit NULL) or chaining up otherwise.
      We will use this for g_settings_get_user_value().
  10. 24 Jun, 2013 2 commits
  11. 31 Mar, 2012 1 commit
  12. 27 Jan, 2012 1 commit
    • Allison Karlitskaya's avatar
      GSettings: two memory use fixes · da386705
      Allison Karlitskaya authored
      First, correct a rather dubious case of accessing a GSettingsSchemaKey
      after clearing it.  This was technically okay because only the key name
      was accessed (and it is not owned by the struct) but it looks very
      Second, have g_settings_backend_write() sink the passed in GVariant*.
      Not all backends get this right, and I'm starting to like the pattern of
      virtual function wrappers being responsible for sinking the parameters
      that they are documented as consuming.
  13. 22 Dec, 2011 1 commit
  14. 21 Nov, 2011 1 commit
  15. 04 Oct, 2011 2 commits
  16. 21 Sep, 2011 1 commit
  17. 06 Sep, 2011 1 commit
    • Allison Karlitskaya's avatar
      GSettingsBackend: emit changes to correct thread · 27fbaf37
      Allison Karlitskaya authored
      When g_settings_apply() is called on a delayed settings backend and
      there is a D-Bus error when communicating with dconf-service, recent
      versions of the dconf GSettingsBackend call a function in GLib that
      improperly delivered the signal directly instead of using
      This patch fixes this function to route in the same way as the others so
      that the signal is dispatched in the proper GMainContext.
  18. 29 Aug, 2011 1 commit
    • Matthias Clasen's avatar
      Spelling fixes · 1b28408b
      Matthias Clasen authored
      Spelling fixes in comments and docs, provided by
      Kjartan Maraas in bug 657336.
  19. 20 Jun, 2011 1 commit
  20. 07 May, 2011 1 commit
  21. 11 Apr, 2011 1 commit
  22. 07 Jan, 2011 1 commit
  23. 05 Jan, 2011 1 commit
  24. 29 Nov, 2010 1 commit
  25. 03 Oct, 2010 1 commit
    • Allison Karlitskaya's avatar
      Bug 623400 - acquire context before dispatching · 0bd50b39
      Allison Karlitskaya authored
      For GSettings.
      Use the functionality introduced in the last commit to simplify our
      notify dispatching and increase the safety of doing so (by ensuring that
      the context is acquired in the current thread for the duration of the
      This closes bugs #623400 and #629849.
  26. 24 Sep, 2010 1 commit
  27. 09 Sep, 2010 1 commit
  28. 22 Jul, 2010 1 commit
  29. 07 Jul, 2010 2 commits
  30. 06 Jul, 2010 1 commit
  31. 24 Jun, 2010 1 commit
  32. 17 Jun, 2010 2 commits
  33. 16 Jun, 2010 1 commit