GDataSet is mainly used by GObject. Usually, when we access the private
data there, we already hold another lock around the GObject.
For example, before accessing quark_toggle_refs, we take a
OPTIONAL_BIT_LOCK_TOGGLE_REFS lock. That makes sense, because we anyway
need to protect access to the ToggleRefStack. By holding such an
external mutex around several GData operations, we achieve atomic
updates.
However, there is a (performance) use case to update the qdata
atomically, without such additional lock. The GData already holds a lock
while updating the data. Add a new g_datalist_id_update_atomic()
function, that can invoke a callback while holding that lock.
This will be used by GObject. The benefit is that we can access the
GData atomically, without requiring another mutex around it.
For example, a common pattern is to request some GData entry, and if
it's not yet allocated, to allocate it. This requires to take the GData
bitlock twice. With this API, the callback can allocate the data if no
entry exists yet.
There are a handful of APIs in libgirepository which are used on
performance-sensitive code paths in language bindings (such as looking
at arguments when doing function calls). Historically libgirepository
has provided a stack-allocated variant for them, which avoids returning
a newly allocated `GIBaseInfo`. Since moving to glib.git and porting to
`GTypeInstance`, that stack allocated version has been broken.
This commit fixes it, by exposing obfuscated stack allocatable versions
of `GITypeInfo` and `GIArgInfo`, which are the two `GIBaseInfo`
subtypes which can be returned by the stack allocation functions.
The commit includes unit tests for them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3217
The previous commit enabled the `/run/mount/utab` monitoring. The problem
is that the `mount-changed` signal can be emitted twice for one mount. One
for the `/proc/mounts` file change and another one for the `/run/media/utab`
file change. This is still not ideal because e.g. the `GMount` objects for
mounts with the `x-gvfs-hide` option are added and immediately removed.
Let's enable the `mnt_monitor_veil_kernel` option to avoid this.
Related: https://github.com/util-linux/util-linux/pull/2725
The `GUnixMountMonitor` object implements monitoring on its own currently.
Only the `/proc/mounts` file changes are monitored. It is not aware of the
`/run/mount/utab` file changes. This file contains the userspace mount
options (e.g. `x-gvfs-notrash`, `x-gvfs-hide`) among others. There is a
problem when `/sbin/mount.<type>` (e.g. `mount.nfs`) helper programs are
used. In that case, the `/run/mount/utab` file is updated later than the
`/proc/mounts` file and thus the `GUnixMountMonitor` clients (e.g.
`gvfs-udisks2-volume-monitor`, `gvfsd-trash`) don't see the userspace
options until the next `mount-changed` signal. Let's use the `libmnt_monitor`
API for monitoring instead and emit the `mount-changed` signal also when the
`/run/mount/utab` file is changed.
Related: https://issues.redhat.com/browse/RHEL-14607
Related: https://github.com/util-linux/util-linux/pull/2607
It's not clear what this code comment tries to tell us. Yes, when we
make changes, we must take care that the changes are correct and update
the relevant places.
It seems long obsolete. Drop it.
This partly reverts commit d7dd9aefd8 ('placed a comment about not
changing CArray until we have').
g_object_weak_ref() documentation refers to GWeakRef as thread-safe
replacement. However, it's not clear to me, how GWeakRef is a
replacement for a callback. I think, it means, that you combine
g_object_weak_ref() with GWeakRef, to both hold a (thread-safe) weak
reference and get a notification on destruction.
Add a test, that GWeakRef is already cleared inside the GWeakNotify
callback.
Adapt gi-compile-repository sources to compile against the updated
libgirepository that is included with GLib.
This also renames "g-ir-compiler" to "gi-compile-repository" to avoid
overwriting the existing binary and to simplify the binary name going
forward.
For the same reasons as in commit 71061fdcb3, but in this
case we can’t downgrade the version of Meson on the CI runner, so just
tell it to shut up instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3238
This was introduced by me in commit
1eec66c898, as the ownership transfer
semantics of `gi_typelib_new_from_mapped_file()` were not blatant.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3237
To enable tests which depend on libgirepository's GIR and typelib,
we need to refactor the order we're currently building these items.
We can also move everything under girepository/ to cleanup the
top-level.
also, make the global variable "static const". That may allow the linker
to place the variable into read-only memory, so we are a bit more confident
that it cannot be modified.
We now only support creating `GIRepository` instances as normal
GObjects, not as a global singleton. This makes the semantics of the
class a bit more standard and, in particular, makes it easier to ensure
that everything is freed when we’re done with libgirepository. This is
particularly useful for unit testing, but should also be useful when
unloading modules from bindings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Rather than them being set and stored globally, make them members of
`GIRepository`. This helps us move away from the concept of a global
singleton `GIRepository`.
This is slightly complicated by the fact that the library paths are
needed within the module loading code in `GITypelib`, but at that point
the `GITypelib` doesn’t have access to its parent `GIRepository` to call
`gi_repository_get_library_path()`, so we have to cache them in
`typelib->library_paths`.
It also means that it’s no longer possible to retrieve the ‘unset’ paths
from the globals, so the test for that is removed from
`repository-search-paths.c`.
This commit makes some API breaks, but that’s OK because libgirepository
has not been in a stable release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This means they’re implemented in the same file as the typelib search
path, so it’s easier to refactor the code.
This adds `gi_repository_get_library_path()` to expose the library path,
both publicly and to internal users in `gitypelib.c`. And unit tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GBytes` provides a way of handling const memory blobs, stolen memory
blobs, and mapped files. Rather than having `GITypelib` implement all of
those itself, just take a `GBytes` as input.
This is an API break, but libgirepository hasn’t been in a stable
release yet.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeUnion` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeEnum` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`GIIrNodeField` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
This also includes some offset validity changes which were forgotten
from commit 515b3fc1dc.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeVFunc` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`class_closure` isn’t actually meaningfully set anywhere in the code yet
(there are FIXME comments), so I’m not sure of the best type for it. But
generally `unsigned` is more widely used than signed `int`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`GIIrNodeType` is built dynamically at runtime (rather than being
mmapped from disk), so its types can accurately reflect their runtime
semantics, rather than an on-disk format.
As part of this, switch from `atoi()` to `g_ascii_string_to_unsigned()`
for parsing the relevant fields from a GIR XML file. This means we now
get error handling for invalid integers.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
`g_strdup(NULL)` is guaranteed to return `NULL`, so there’s no need to
branch to handle that.
Add a stub private doc comment to hold a `(nullable)` annotation for
that argument, though, so that information isn’t lost.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Might as well move to a modern way of declaring GObjects. This means
that `GIRepository` is no longer derivable, but it would be a bit
unexpected if anyone was deriving from it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This is just for future reference for people reading the code in future.
I was going through and checking to see if any of them needed to be made
`const` (none of them did).
I did find a couple of memory leaks though; see the following commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
By shifting responsibility for ensuring that the lifetime of a
`GIRepository` always exceeds the lifetime of any of its `GIBaseInfo`s
to the user.
Keeping a weak ref from each `GIBaseInfo` to its `GIRepository` would be
too expensive (`GIBaseInfo`s are supposed to be cheap to create and
destroy, as they are used within function calls in language bindings).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3234
Don’t allow the `pages` job to be run (even manually) on post-merge
pipelines. It’s not particularly useful, and GitLab doesn’t like having
a manual job with unsatisfied dependencies in a pipeline:
```
'pages' job needs 'coverage' job, but 'coverage' is not in any previous stage
'pages' job needs 'style-check-advisory' job, but 'style-check-advisory' is not in any previous stage
```
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3847#note_1986044
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
g_strndup() internally uses strncpy(), while g_strdup() uses memcpy().
Most likely, memcpy() is faster.
Instead of strlen()+g_strndup(), use g_strdup() as we don't need the
length.
