Setting the main thread's scheduler settings is not reliably possible,
especially not if SELinux or similar mechanisms are used to limit what
can be done.
As such, get rid of all the complicated code that tried to do this
better and use a separate thread for spawning threads for the global
shared thread pool. These will always inherit the priority of the main
thread (or rather the thread that created the first shared thread pool).
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2769
g_print(), g_printerr() and all the g_log() functions used to always
duplicating a string when printing even if there's nothing to format.
This can be avoided in many cases though, so if a string has no formatting
directive, we can just write it as it is without duplicating and free'ing
it.
From my tests the potential `strchr` overhead is minimal.
We may not be able to fix GTasks broken design,
but at least we should document it and not let
users stumble into this bear trap without warning.
Helps: #1346
Add static inline versions of these functions
that boil down to just an memcpy. ag_string_append_len
is used quite a bit in GMarkup and GTK's css parser.
Due to an oversight (I guess), per-desktop default values (which come
from override files such as this one:
https://github.com/endlessm/gnome-shell/blob/master/data/00_org.gnome.shell.gschema.override)
were not checked when getting a GSettings value via a `GSettingsAction`.
Per-desktop default values are correctly returned via all other
GSettings query paths (see calls to
`g_settings_schema_key_get_translated_default()`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`memcpy(NULL, ., n)` and `memcpy(., NULL, n)` are undefined behaviour,
even if *n* is zero.
When len is 0 here, callers are allowed to pass in null data, and
GPtrArray also does not guarantee to have allocated rarray->pdata yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
ptr_array_new(len, ., TRUE) ensures that there are at least len+1
elements in pdata, and that pdata[0] is null, but leaves the rest of
pdata uninitialized. After copying the array data into pdata[1] to
pdata[len-1] inclusive, we still need to make sure pdata[len] is a
null terminator.
Note that if len is 0, then pdata is not guaranteed to be non-null. If
it's null, then we can't add null-termination to it until its size
is updated.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2877
Signed-off-by: Simon McVittie <smcv@collabora.com>
This has historically failed on Debian autobuilders, and as a result we
have had a patch for a long time that turned a failure here into a
g_test_skip(). It's not clear whether this still happens, so I'm now
assessing whether the patch can be dropped; but if the prlimit() call
can fail for whatever reason, it would be useful for the error message
to say what limit we were trying to set.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commit 1422e5f812. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
This reverts commit da7a31a052. The renaming of parameters implicitly introduced "closure" annotations in the documentation which are wrong on callbacks.
The "disguised" attribute is there only for backward compatibility; we
use the "pointer" attribute as the authoritative way to indicate a
typedef to a struct pointer.
Plain Old Data (POD) types with or without a representation in the GType
type system can still have a copy and/or a free function. We should
allow annotating these types with their corresponding functions for
copying their data into a new instance, and freeing their data.
From a language bindings perspective, POD types should have a boxed
GType wrapper around them, so they can use the generic GBoxed API to
copy and free instances; from a documentation perspective, though, it'd
be good to have a way to match a structured type, like a struct or a
union, with its copy and free functions.
In order to do that, we add two new header block annotations:
- (copy-func function_name)
- (free-func function_name)
These annotations work exactly like ref-func and unref-func for typed
instances:
/**
* GdkRGBA: (copy-func gdk_rgba_copy)
* (free-func gdk_rgba_free)
* @red: ...
* @green: ...
* @blue: ...
* @alpha: ...
*
* ...
*/
The function is stored in the GIR data as two new attributes for the
`<record>` and `<union>` elements:
<record name="RGBA"
c:type="GdkRGBA"
copy-function="gdk_rgba_copy"
free-function="gdk_rgba_free"
glib:type-name="GdkRGBA"
glib:get-type="gdk_rgba_get_type"
c:symbol-prefix="gdk_rgba">
The annotations are not mandatory.
See: #14
