As per the previous few commits, explicitly document the established
reference counting semantics of the method call closure for
`g_dbus_connection_register_object_with_closures()`.
This isn’t ideal, but
`g_dbus_connection_register_object_with_closures()` has had these
semantics for 10 years now, and it’s a bit late to change them to
something neater.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
It’s not leaked, it’s transferred forwards to the eventual
`g_dbus_method_invocation_return_*()` call.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3559
This reverts commit 092fedd5f0.
This was not the right change to make, and I shouldn’t have accepted the
MR. The situation is laid out in this comment:
https://gitlab.gnome.org/GNOME/glib/-/issues/2600#note_1385050
tl;dr: The reference on the `GDBusMethodInvocation` which is transferred
in to the `GDBusInterfaceMethodCallFunc` is balanced by a reference
transferred to `g_dbus_method_invocation_return_*()`. This is how the
refcounting has always worked for these functions, and even if we’d
probably arrange things differently if the code was written now, we
can’t change those semantics without breaking API.
In particular, bindings have various bits of custom code to account for
these reference tranfers (since they can’t be represented using
gobject-introspection annotations), so changing the semantics will break
bindings.
Fixes: #3559
Parts of the `dbus-appinfo` test need support for converting an FD to a
path, and Hurd doesn’t currently allow that (see
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4396#note_2279923).
Since there’s no fix for that visible in the medium term (new kernel
APIs will need to be added), skip parts of the `dbus-appinfo` test which
require that functionality for now.
This prevents the whole test from failing, and means we can usefully get
results from the parts of it which don’t depend on converting FDs to
paths.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3538
Don’t want any argument escaping problems, given that some of these
variables can be controlled by unprivileged users who are running CI
jobs.
The except:variables and rules:if lines don’t need to be quoted because
they are [GitLab CI/CD Variable
Expressions](https://docs.gitlab.com/ee/ci/jobs/job_rules.html#cicd-variable-expressions)
rather than bash script.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It doesn’t list all mounts, only the ones you’d expect to see in a file
chooser sidebar.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3555
The docs for the constructed vfunc make it clear that when called
constructed properties are already set. However, the first place where a
user would look for is the flag's documentation.
A settings schema that extends another schema should return TRUE for
all keys that are present in the extended schema. The list of keys
returned by list_keys() already includes these,
so it makes sense to include them in has_key().
Signed-off-by: Johannes Marte <johannes.marte@wolfvision.net>
Move details about the `log_domain` parameter being `NULL` or an empty string
for the default application domain from argument descriptions to the main
function descriptions.
This ensures concise argument descriptions while providing a clear
explanation of exceptions in the function body.
Add a missing `(nullable)` annotation for the `log_domain` parameter in the
`GLogFunc` callback. This ensures consistency with the documentation and
usage in functions like `g_log_set_handler`, where `log_domain` can be `NULL`.
Without this annotation, the GIR file generated from the C source does not
reflect the nullability of `log_domain`, leading to potential issues in
language bindings and other introspection-based tools.
This change updates the documentation in `glib/gmessages.c` to include the
nullable annotation and clarifies the expected behavior of the `GLogFunc`
callback.
Fixes#3552
This is meant to improve debugging of thread-related problems outside
of GLib. This commit adds an implementation for Posix. The Win32
implementation is a stub.
Test included.
Fixes: #3546
Sender can be NULL if not specified by the caller, e.g. on peer-to-peer
connections.
Interface name can be NULL on method calls if it was not specified by
the sender.
Both is explicitly allowed by the DBus specification.
In my experience, it isn't actually useful to have the program
name as part of the thread name (we don't do that for other threads
that we create: pool-spawner, gmain, gdbus, ...) and the size limit
of 16 means that there really isn't enough space for it.
But what is somewhat useful is to have different threads have different
names, so number the pool threads: pool-0, pool-1, ...
`g_setenv()` is unsafe to use after any other threads have started,
which might have happened once GLib is initialised.
Avoid that problem by using `g_test_trap_subprocess_with_envp()` to
launch the existing subprocesses with the desired environment. This API
was added after these tests were written, but it’s a perfect fit for
them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
systemd 257 will now set `DEBUG_INVOCATION=1` in the execution context
of services which need to be debugged — for example if they’ve failed
and been restarted (and `RestartMode=debug`).
If we handle `DEBUG_INVOCATION=1` as being equivalent to
`G_MESSAGES_DEBUG=all`, then any processes using GLib’s default log
writer function (or `g_log_writer_default_would_drop()`) automatically
gains support for this feature.
See https://mastodon.social/@pid_eins/113548825942383777
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The default value for max_unused_threads has been 2 since 2012.
Core counts have gone up since then, and nowadays, it would be
much better to keep more of the threads alive for a little while.
This commit bumps the max_unused_threads default value to 8.
Fixes: #3545
