This is a minor performance improvement, since the pspec list for the
class now only has to be modified once, rather than twice.
It also means we now have the `GParamSpec` pointers to hand in a `props`
array, which will be used in the upcoming commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This lets the compiler tell us if we’ve accidentally missed a property
implementation from `get_property()` or `set_property()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As per previous commit we used atomic logic to handle the cancellation,
but that lead to a slightly different behavior because the file monitor
was then marked as cancelled before the vfunc implementation was called.
Use similar behavior now (by still relying on the atomic logic), by
marking the state as about-to-cancel as soon as we're starting the
cancellation (preventing other threads to cancel it), and eventually
fully marking it as cancelled.
The cancelled state may be set and read by different threads, so ensure
that it's stored and managed in an atomic way.
We could in fact end up check for `g_file_monitor_is_cancelled()` in a
thread and `g_file_monitor_cancel()` or `g_file_monitor_emit_event` in
in another one.
Adding some initial test for the compiler behavior and its expected
output.
Also, when using sanitizers we want to be able to test the compiler memory
management.
We were reusing the same logic everywhere, while we can just reuse an
unique class to base our tests on that avoids having to copy-and-paste
code for no good reason
Add some basic support for having glib-tests-only python libraries that
can be shared across the various projects, so that we don't have to
maintain multiple copies of them.
This replaces `g_dbus_connection_register_object_with_closures()`, and
becomes the new binding-friendly version of
`g_dbus_connection_register_object()`.
The problem with `g_dbus_connection_register_object_with_closures()` is
that the `method_call_closure` kept the reference counting semantics of
`GDBusInterfaceMethodCallFunc`, in that the `invocation` argument was
`(transfer full)`, even though it was wrapped in a `GClosure`. This
couldn’t be described in introspection annotations, so the
`GDBusMethodInvocation` was being leaked by bindings. Some bindings
added workarounds to fix the leak at our direction (see
https://gitlab.gnome.org/GNOME/glib/-/issues/2600#note_1385050), which
meant we could no longer change the reference counting behaviour without
breaking those bindings (see #3559).
So let’s start afresh with
`g_dbus_connection_register_object_with_closures2()`, with correctly
defined reference counting semantics (the `GDBusMethodInvocation` is
`(transfer none)`) from the start.
Unfortunately we can’t add a `(rename-to)` annotation to the new API, as
that would effectively be an API break for existing binding code which
uses the old API via that rename.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3560
Move the shebang line from the full Python path of the build
machine to the first Python on the path during runtime. Set
the shebang in the main meson.build file so that it can be
overridden in one place if needed.
Fixes: #3331
As gettext does:
* if C locale is used to set a value, set the untranslated value, i.e.
key=value and not key[C]=value;
* if C locale is used to get a value, return the untranslated value,
i.e. not the value from key[C]=value, if it ever exists, and do not
consider C as an undefined locale otherwise.
Fixes: #3578
These refcount changes cannot possibly fix any race condition because
there is no guarantee that the g_source_ref() will be called in this
thread before any g_source_unref() that might happen on another thread.
We would have to take the ref sooner for it to be effective.
It's also not clear why we take a ref at all, since the source is
already being disposed and there's no explanation of why we should
resurrect it here. It can't be finialized until the call to dispose is
finished, so it's unclear what we are guarding against.
I'm not sure about the correctness of this code and make no promises
that there are no bugs here, but I think this change shouldn't make
anything worse.
Link to the toolchain requirements, which are kept up to date, rather
than duplicating them across multiple documents.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will warn if GLib is configured with a toolchain which doesn’t
support C11. We currently require C99. If nobody complains (as directed
by this warning) we will start to require C11 in the next unstable
release series (2.85).
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3574#note_1859924
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Prevent to access to a disposed gsource in the GCancellable cancelled
signal callback.
Due to the fact that the signal is called in the same thread in which
the cancellable get cancelled, we may receive the callback just after
the GSource has been disposed or during its disposal.
To prevent this, let's pass to the signal a pointer to the source itself
and nullify atomically the first time we're calling a callback or
disposing it.
In case the dispose function wins the race, then the callback will just
do nothing, while the disposal will continue as expected.
In case the callback wins the race, during the concurrent disposal we'll
just wait for the callback to be completed, before returning the disposal
itself that will likely lead to freeing the GSource.
Closes: #3448
