GSettings: delay backend subscription

Desktop / GNOME / GLib - Ryan Lortie [desrt.ca] - 19 November 2014 12:40 UTC

GSettings objects begin watching for changes as soon as they are created in order that they can emit the "changed" signal.

In the case of dconf, if we want to be able to emit the changed signal, we need to go on the bus and add some match rules. This requires creating the dconf helper thread and also requires initialising GDBus (which creates another thread).

Some users of GSettings are never interested in the "changed" signal. One of these users is the glib-networking code that gets run every time a new network connection is created.

Some users are reporting that they are annoyed that simply establishing a network connection would spawn two extra threads and create a D-Bus connection.

In order to avoid doing unnecessary work for these simple uses, delay the subscription until we know that we will actually need to do it.

We do this in a simple way, using a simple argument: in order for the user to care that a value changed then they must have:

1) watched for a change signal; and then 2) actually read a value

If the user didn't actually read a value then they cannot possibly be interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it ever changed, since they have nothing to compare the new value with).

This really is a behaviour change, however, and it does impact at least one user: the 'monitor' functionality of the GSettings commandline tool, which is interested in reporting changes without ever having known the original values. We add a workaround to the commandline tool in order to ensure that it continues to function properly.

It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the (correct) assumption that it would not have been possible to miss a change signal by virtue of not having returned to the mainloop. Although this argument is true, this pattern is extremely non-idiomatic, and the problem is easily avoided by doing things in the usual order.

We never really talked about change notification in the overview documentation for GSettings, so it seems like now is a good time to add some discussion, including the new rules for when one can expect change signals to be emitted.

https://bugzilla.gnome.org/show_bug.cgi?id=733791

8ff5668 GSettings: delay backend subscription
gio/gsettings-tool.c | 13 +++++++++++++
gio/gsettings.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 56 insertions(+), 4 deletions(-)

Upstream: git.gnome.org

  • Share