Don't drop resets from a GDelayedSettingsBackend when the writability
changes. Resets will always succeed, even against non-writable keys and
some people (gnome-screensaver) are using them in a way that they would
want them not to be forgotten.
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
dispatch).
This closes bugs #623400 and #629849.
- hold a lock while accessing the tree of delayed values
- use weak reference counts with the owner object to avoid doing
g_object_notify on a dead object
- dispatch the "has-unapplied" notify to the proper main context
This commit fixes up a few race conditions in the GSettingsBackend, mostly with
respect to change notifications occuring at the same time as the last reference
count on a GSettings is dropped. With GDBus feeding us our incoming signals in
a separate thread, this is something that could easily happen.
- if a key becomes mandatory, drop it from the changeset
- if we still get failing writes (ie: because of a race) then drop the
entire changeset and signal that it happened
