| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
When used with the "fast" (optimistic concurrency) API, the engine library
emits a change notification local to a process after a change is initiated
from that process. Previously, it would emit this notification even if the
newly written value was the same as the previous value (according to that
process's view of the state). After this change, the local change
notification is not sent unless the new value is different from the
current value (as seen by that process).
|
|
|
|
|
| |
It would be wrong to change the in_flight queue, so seal it to ensure
that it is consistently sealed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes the dbus-leak tests by dropping the cached
GDBusConnection objects references when the bus connection is closed.
The issue was introduced with recent changes made to GLib[1]
where invoking g_test_dbus_down() will fail after a
timeout if the GDBusConnection object for the session bus leaks.
Given g_test_dbus_down() will first close the connection before checking
for leaks unreffing the object when the connection is closed should fix
the issue.
[1] https://gitlab.gnome.org/GNOME/glib/merge_requests/963
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
|
|
|
|
| |
that need to be mocked out
|
| |
|
|
|
|
|
|
| |
Reduce the number of in-flight requests to one, so as to increase
chances of merging pending requests. Drop the in-flight queue since
it is no longer useful, replacing it with optional changeset.
|
|
|
|
|
|
|
|
|
|
| |
Instead of queuing changes and sending them to a writer one by one,
coalesce them into a single changeset.
Coalescing changes requires a little bit more work on the client side,
see implementation of `dconf_changeset_change`, but it has chance to
substantially reduce the total amount of work necessary and avoid costly
disk writes.
|
|
|
|
|
|
|
|
| |
Otherwise we leak it as can be seen in
https://source.puri.sm/guido.gunther/phosh/-/jobs/1868
This unbreaks phosh's CI build under valgrind.
|
|
|
|
|
|
|
| |
This enables structured logging for all parts of dconf, which will make
it easier to check for certain log messages in the unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
| |
This is useful for JHBuild environments and systems that don't want
to use /etc/dconf.
https://bugzilla.gnome.org/show_bug.cgi?id=739299
|
|
|
|
| |
GMAXUINT
|
|
|
|
|
|
|
|
| |
state transition is atomic
Update comment about threading, documenting the new lock
Add documentation comments for new utility functions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
subscriptions to the same path
Remove accidental whitespace change
Simplify branching in watch_fast and unwatch_fast
Indentation fixes
Store the subscription counts directly in the hash table pointer instead of mallocing ints
Add documentation comments for new utility functions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build currently, unintentionally, depends on side effects, namely:
that a variable defined in a meson.build file will be valid for any
other included meson.build file, until it gets re-defined.
We use the same `deps` variable in many places, and we end up depending
on the inclusion order when we get to the client library, which depends
on the gsettings backend defining the `deps` variable.
Reviewed-by: nobody
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
|
|
|
|
|
|
| |
Having trailing commas in place means that if another source file or
parameter is added to the end of the list or function, there won't
be noise when adding the comma to the line above.
|
|
|
|
|
|
|
|
|
| |
The current meson build files make heavy use of meson's
`project_name` function. However this makes difficult for any
developer to find for given program/library/file names. The project
name is also never going to change.
Due to this reason these calls have been changed for `dconf` itself.
|
|
|
|
|
|
|
|
|
| |
meson is able to generate internal dependencies for handling built
libraries. These internal dependencies depend on other dependencies
as well, based on the includes exposed by their headers.
This have been fixed by using proper internal dependencies for these
libraries.
|
|
|
|
|
|
|
|
|
|
|
| |
dconf builts a number of internal static libraries which in some
cases are duplicated. This duplication comes from autotools that
used to built two libraries for each library, one with PIC enabled
and the other one without it.
This has been changed to build only one library for each library to
be built, except `libdconf-common-hidden` which hides some symbols
for the GIO module to be built.
|
|
|
|
| |
for the root path
|
|
|
|
|
|
|
|
|
|
| |
meson does not allow to build source code inside the source code
tree, for this reason there is no need for .gitignore files to
ignore built files.
This patch removes .gitignore files which are no longer needed.
https://bugzilla.gnome.org/show_bug.cgi?id=784910
|
|
|
|
|
|
|
| |
To avoid the burden of maintaining multiple build systems, this
patch removes autotools support.
https://bugzilla.gnome.org/show_bug.cgi?id=784910
|
|
|
|
|
|
|
|
| |
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=784910
|
|
|
|
|
|
|
| |
There is no reason that the read_through queue should not be 'const', so
expose it as such.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
|
| |
Add a flag that allows checking the default value without constructing a
read_through queue. Make use of this new flag to simplify code in a
couple of places.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
| |
Delete the separate dconf_engine_read_user_value() and merge its
functionality into dconf_engine_read() by adding a flags field.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
| |
This will soon contain an extra enum.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
| |
Add an API to dconf-engine (and exposed via DConfClient) for getting a
list of locks that are present in a given dconf profile.
https://bugzilla.gnome.org/show_bug.cgi?id=758864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support to dconf-engine for opening "runtime" profiles.
These profiles are intended to be symbolic links or plain files that
will live either in XDG_RUNTIME_DIR/dconf/profile or
/run/dconf/user/$(uid).
This is intended to allow for a PAM module that makes complex decisions
about application of a specific policy to a user and sets up the profile
at login time, thus preventing the need for this complex decision to be
a part of every program that uses dconf. This PAM module would not be
part of dconf, but would rather be a part of a dconf-aware system
administrator framework.
In the case that the profile file is found in /run/dconf, then it will
not be possible for the user to override the profile selection,
including via the DCONF_PROFILE environment variable. This provides a
mechanism for lockdown that is slightly more difficult for a user to
circumvent. In theory, this is pointless since it can still be defeated
with LD_PRELOAD, but in practice this raises the bar quite a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=751417
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the usual way async in dconf works, we can start getting replies
immediately (without returning to the mainloop). For this reason, we
must be sure that we do not modify the OutstandingWatch structure at any
point after we've issued even one call because the results may already
be coming in.
For this reason, we must add up the 'pending' count in a separate loop
run before we start making the calls.
https://bugzilla.gnome.org/show_bug.cgi?id=724929
|
|
|
|
|
|
|
| |
file-db databases don't have an associated D-Bus bus type, so don't try
to install match rules for them.
https://bugzilla.gnome.org/show_bug.cgi?id=723553
|
| |
|
|
|
|
|
|
|
|
| |
This is a new database type that is simply an absolute path to a gvdb
anywhere on the filesystem. Change notification is not supported.
This is intended to be used by things like gdm that wish to install
databases (somewhere in /usr) as part of the software.
|
|
|
|
|
| |
If we can't find a given profile in /etc then look for it in the
XDG_DATA_DIRS.
|
|
|
|
|
|
|
| |
Check incoming signals for non-sense before bubbling them up to higher
layers. This will avoid dconf APIs feeding invalid key names to
applications during change notifications in the case that we're fed
invalid data over D-Bus.
|
|
|
|
|
|
|
|
|
| |
Testing uncovered a case of a shadowed variable in the signal handling
code of the engine: the object path on which a signal arrived was being
shadowed by the 'path' variable used when deserialising the content of
the signal, causing the signal to fail to be delivered.
Rename the D-Bus path variable to 'object_path' to avoid the issue.
|
|
|
|
|
|
|
|
|
|
|
| |
Testing revealed that we were transmitting any change signal that came
in from the bus up to user code, even if the engine in question was not
interested in receiving the signal.
This is a problem in the case that two DConfClient objects exist for
different profiles. In that case, we'd get crosstalk between the
subscriptions that each client had made and change notifications would
appear in both clients even if the change only affected one.
|
|
|
|
|
| |
Wire through WritabilityNotify signals from the engine. This has been
unimplemented for a very long time...
|
|
|
|
|
|
|
| |
Allow specifying a profile when calling dconf_engine_new(). This will
allow us to avoid setting/unsetting the DCONF_PROFILE environment in
testcases from contexts where other threads may be reading from the
environment.
|
|
|
|
|
|
| |
We use a NULL handle in case we don't care about the return value. In that
case, we certainly don't care about the return type either, so use NULL for
expected_type in this case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On failure to open a gvdb file in /etc/dconf/db we would issue a warning
once per process -- even if multiple files were missing.
This was enforced using a static variable.
An unfortunate side effect of this global state is that the testcases
couldn't reliably know if to expect the error or not. This issue was
side-stepped by running any cases that may emit the warning under a
fork, but that made it difficult to debug some of the cases.
Rework the backends not to use global state for the flag and instead
store it per-source.
Remove a use of g_test_trap_fork().
|
|
|
|
|
|
|
| |
Make sure we actually acquire the sources lock on entry to
dconf_engine_read_user_value().
Uncovered during testing.
|
|
|
|
|
|
|
|
|
| |
Add a DCONF_ERROR error domain with associated DConfError enum type.
Use this instead of the adhoc approach that we've been taking up to this
point.
https://bugzilla.gnome.org/show_bug.cgi?id=704638
|
|
|
|
|
|
|
|
|
| |
Don't use the access() system call from the service source because this
bypasses the mocking layer in the testsuite. Use gvdb_table_new()
instead. This also avoids an extra syscall.
Also: change a couple of criticals to warnings because they are not
programmer errors.
|
|
|
|
| |
We ought to be including this from each .c file.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement g_settings_backend_read_user_value() in DConfSettingsBackend.
This will help us support g_settings_get_user_value() properly.
We add a new engine API to support this as well. It takes a
read_through queue, even though we don't bother using that from
DConfSettingsBackend.
https://bugzilla.gnome.org/show_bug.cgi?id=668233
|
|
|
|
|
|
|
|
|
|
|
| |
When we do change operations, make sure we seal our DConfChangeset
before sharing it between threads.
This will ensure it gets sealed in only one thread instead of being
implicitly sealed in two different threads at the same time when each of
them calls dconf_changeset_describe().
https://bugzilla.gnome.org/show_bug.cgi?id=703073
|
| |
|
|
|
|
|
|
|
|
| |
We should not send empty changesets to the service so just ignore them
when we get them.
This now means that an empty 'dconf load' will not send any D-Bus
messages (and will not cause D-Bus activation).
|