It’s a bad idea to use it without some care for how much it’s being
called in parallel, or dependencies between tasks. If the thread pool
gets exhausted by too many inter-dependent calls to
`g_task_run_in_thread()` then the process will livelock.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with the previous commit.
The logic has to be a little contorted here to avoid leaving the context
locked after emitting the critical warning. Execution does (and should)
continue after a critical warning by default, so we should do our best
to recover.
Inspired by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3302.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The documentation was fairly clear before, but we can make it clearer:
it’s a programming error to call `g_main_context_release()` if you have
not received a true return value from `g_main_context_acquire()` before.
Inspired by https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3302.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We need a way to initialise refcounted types placed in static storage,
or on the stack. Using proper macros avoids knowing the magic constant
used for grefcount and gatomicrefcount.
Update a series of error messages to use `g_set_error_literal` instead
of `g_set_error`. This should prevent `format-nonliteral` compiler
issues when `-Werror` is configured:
../gio/gunixconnection.c: In function ‘g_unix_connection_receive_fd’:
../gio/gunixconnection.c:183:9: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
183 | nscm);
| ^~~~
../gio/gunixconnection.c:217:20: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
217 | nfd);
| ^~~
../gio/gunixconnection.c: In function ‘g_unix_connection_receive_credentials’:
../gio/gunixconnection.c:601:24: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
601 | nscm);
| ^~~~
This is similar to a previous change [1] made to `gunixconnection.c`.
[1]: 44b3d5d80445234041f6c59feb89645f7102c3a4
Signed-off-by: James Knight <james.d.knight@live.com>
In non-perf mode, we were making only one thread to win the race to increase
the value, but since we're launching more threads anyways let's allow
more of them to have a chance to do something, to make the test more
valuable, even if it's still quick enough.
This removes the `comment` member of the GKeyFileGroup structure, which
seemed intended to distinguish comments just above a group from comments
above them, separated by one or more blank lines. Indeed:
* This does not seem to match any specification in the documentation,
where blank lines and lines starting with `#` are indiscriminately
considered comments. In particular, no distinction is made between the
comment above the first group and the comment at the beginning of the
file.
* This distinction was only half implemented, resulting in confusion
between comment above a group and comment at the end of the preceding
group.
Instead, the same logic is used for groups as for keys: the comment
above a group is simply the sequence of key-value pairs of the preceding
group where the key is null, starting from the bottom.
The addition of a blank line above groups when writing, involved in
bugs #104 and #2927, is kept, but:
* It is now added as a comment as soon as the group is added (since a
blank line is considered a comment), so that
`g_key_file_get_comment()` returns the correct result right away.
* It is always added if comments are not kept.
* Otherwise it is only added if the group is newly created (not present
in the original data), in order to really keep comments (existing and
not existing).
Closes: #104, #2927
Since commit c0ca3f99 this test is strictly depending on GDesktopAppInfo
that is not defined or available in macos, so skip the test as we do for
windows.
We could have done this at meson level too, but keeping it this way is
probably a better reminder that this should be adapted for such scenario
one day™
See: https://gitlab.gnome.org/GNOME/glib/-/jobs/2753753
The merge request !2848 added code to automatically detect the module
prefix on macOS, with a test for the Mac #define TARGET_OS_OSX. However,
older versions of the SDK (at least 10.11) don't provide this #define,
leading to build failure. If the #define is missing, fall back to
checking TARGET_OS_MAC. On newer SDKs this symbol is also true for
watchOS, etc., but in those situations TARGET_OS_OSX is available.
Even though having NULL as nullptr should be the standard for newer C++
versions, it may break some headers, so let's not touch it for now.
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/2973
A context iteration we're doing lots of lock/unlocks and that's fine to give
other threads contexts a chance to run, but we're doing it also just to call
other functions that require locking, and this can be avoided.
Other threads can still have a chance to run while releasing the ownership
of the context.
Various gio modules include gmodule.h that requires the
gmodule-visibility.h to be already built.
To make this easier, just provide a dependency and use it where we are
building modules that do not depend on libgio_dep (that already includes
that).
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2982
The generated gir file marks the size parameter as "out" by default. This is wrong in the context of a caller allocated buffer with a given size. Explicitly marking the size parameter as (in) fixes the issue.
In practice, this will never happen.
If `getcwd()` returns `ERANGE` whenever the working directory is ≥
`PATH_MAX`, though, the previous implementation of the loop would run
until `max_len == G_MAXULONG`, and would then overflow when adding `1`
to it for a nul terminator in the allocation.
Avoid that problem by always keeping `buffer_len` as a power of two, and
relying on `getcwd()` to write a nul terminator within the buffer space
it’s given. It seems to do this on all platforms we care about, because
the previous version of the code never explicitly wrote a nul terminator
anywhere.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #98
Various projects are running tests under valgrind, and they are using
the GLib suppresions to avoid false-positive results.
While this is stored in a well-known path for some years, and easy to
figure out from the GLib prefix, it's better to expose it through a
proper pkgconfig variable so that it's easy to get it from any build
system.
This reverts commit 4cad66580b.
Downgrading the criticals was only temporary. Now we’ve branched for
GLib 2.78, the criticals can be reinstated early this cycle, so people
have the maximum time to fix latent bugs in their code.
Fixes: #2951
We were working around that with a call to chdir("."). Internally chdir()
sets up cmd shell-related environment variables, but only if the current
working directory belongs to a volume with a drive letter. For example,
if the current working directory is on a UNC volume like a network share,
the call to chdir() won't help.
Reference:
https://developercommunity.visualstudio.com/t/UCRT-Crash-in-_wspawne-functions/10262748
