If GSettings is uninitialised then g_settings_sync() should very
obviously just return right away (rather than attempting to initialise
GSettings first).
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.
- used in some places as a move-along-as-we-go pointer
- used in other places as a pointer to the fixed base of an array
Switch all users to the first style to avoid a crasher.
