Normally we don't really have emission hooks around, so try to allocate
only tiny array to contain a few of them and in case we exceed that limit,
we go back to use allocated ones.
We used to call this function as unlocked, with a node value that
could be invalid at the point of the call, so let's ensure that when
we call such function it's defined, and then reduce the access to the
signal node members when we're unlocked or after a lock/unlock operation
that may have changed it.
As per this, add more tests handling multiple signal hooks cases that we
did not cover before.
In g_signal_emit_valist() we used to access to param types array and
n_params values after unlocking the mutex, and this might have lead to
making such values unreliable for the current call.
So let's keep them around until we're done with the function call
Since we're locking and unlocking once we've found the signal ID, we
might have performed calls to g_signal_emit_valist() with a signal id
that was already been removed, and thus failing later.
This is not really an issue as inside g_signal_emit_valist() we were
re-checking for the signal id, but we can make this more reliable so
that the first thread that acquires the lock can also be sure to emit.
This allows the `g_free()` wrapper introduced in the previous commit to
only be defined if `free_sized()` is actually available to improve
performance.
This avoids passing an allocation size to every `g_free()` call if it’s
not going to be used, saving a register store instruction each time.
Suggested by Marco Trevisan in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3252#note_1660032
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When using GCC we can take the advantage of __builtin_object_size() to
know the allocated size of a memory area, this generally only works when
some optimization level enabled (-O1 seems enough here) and can provide
us with memory size information for lower-level optimizations.
On some platforms, pointer-sized reads are not necessarily atomic, so we
always need to use the correct atomic access primitives.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When the gnome test runner executes the tests, the test appear to execute in disk
order. This means it sometimes works and sometimes we see breakage in portal-support-snap
and portal-support-snap-classic.
The issue is that some tests create config files but some don't. If they run
in the wrong order, tests see config files they shouldn't and break.
Fix this by deleting the files after each test run, properly cleaning up after
themselves. The cleanup code is based upon gtestutils.c:rm_rf().
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
Adds a helper to truncate UTF8 strings in the middle, allowing to make
them fit certain size constraints.
This function is modeled after similar functionality that has existed
since 2008 in nautilus and in eel before that.
If people do that, it clutters the place up with branches which are not
deleted-on-merge by default. Better to use their own forks.
And the people who are in a position to be able to push directly to
`origin` are not going to be reading the `CONTRIBUTING.md` file, so this
paragraph is noise to most readers anyway.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
GLib can’t grow forever, so we should really only be accepting APIs
which are useful across a variety of projects and which couldn’t easily
live in a separate library.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Point strongly towards `SECURITY.md` so we are not maintaining security
instructions in multiple places.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s a bit confusing to have two files called `README`, especially given
that `README.win32.md` only contains build instructions and none of the
other overview/contribution/bug reporting information that `README.md`
contains.
It feels like these would be better organised by having one top-level
`README.md`, and pointing to the Windows build instructions from there.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Makes the tests compile using clang with meson directly under
termux on android, this build environment does not approve of
overloading libc symbols.
Fixes: #3008
foo
This is a workaround for build conditions one ends up with under termux,
where the defined __ANDROID_API__ level is lower than what is provided
by gcc installed for it, the libc .so nevertheless contains these symbols
thus enabling the codepaths. This definition is only in use when meson
detected the presence of this symbol in the libc.
Fixes#3008
foo
This is a minor style change to better differentiate
signal name by enclosing it in single quotes.
Before:
<emit signal event on instance 0xf14e60 [GdkWaylandToplevel]>
After:
<emit signal 'event' on instance 0xf14e60 [GdkWaylandToplevel]>
- Commit f02ec2f2de added a gsignal fastpath where g_closure_invoke_va()
is directly called from g_signal_emit_valist() skipping signal_emit_unlocked_R()
altogether which it's the function used by gobject_gdb.py to detect
signal emission.
So we update gobject_gdb.py to also detect signals which use this
g_closure_invoke_va() fastpath.
- We also update the existent code to detect marshallers to also
include these:
surface_event_marshaller()
gdk_surface_event_marshallerv()
g_type_class_meta_marshal()
g_type_class_meta_marshalv()
This allow us that for signal emissions which use those marshallers
to keep showing the signal handler frame just after the
<emit signal blabla> line.
In the typical `while (g_file_enumerator_next_file ())` patterns,
there is nothing much checking whether the operation was cancelled
on the GIO side. Unless the user checks for the case, this means
local enumerators always run to completion even if cancelled.
Fix this by checking the cancellable state explicitly for local
enumerators, so there are oportunities for bailing out early if
the enumerator is going through a very large directory.
