This backend periodically watch the memory free ratio through sysinfo().
It signals the applications when the memory free ratio drops to 40%, 30%,
and 20% for LOW, MEDIUM, CRITICAL status, respectively.
The PSI backend is based on Kernel PSI [1]. It monitors the memory
allocation time with in a given time window. If the allocation time
is more than the given threshold, Kernel signal the application to
deliver the memory pressure events.
The current thresholds are:
LOW: 70ms out of 2 seconds for partial stall
MEDIUM: 100ms out of 2 seconds for partial stall
CRITICAL: 100ms out of 2 seconds for full stall
[1] https://docs.kernel.org/accounting/psi.html
This class provides the shared functions, such as sending a signal and
string and value conversion. The backend classes should inherit this
class to get the shared functions.
It adds a configure time check for `sysinfo()`, as some systems don’t
have it.
This will catch regressions like
fc030b2b64 if they happen again in future,
by testing that fallback argument parsing code path in
`g_application_run()`.
Heavily based on the PyGObject `test_local_and_remote_command_line` unit
test at
578a55982a/tests/test_gio.py (L289).
Thanks to Arjan Molenaar for investigating the failure and writing it
up in !4703.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Do an extra check if the options argument is NULL,
This will avoid unnessecary (critical warning).
`g_application_run` calls the code with options == NULL.
Call these vfuncs also for cases where the launching instance
is the primary one. This is what the docs suggest, and it makes
before/after_emit much more useful.
Fixes: #3726
Existing uses of before_emit in GTK will break if an app overrides
before/after_emit without chaining up. Clarify in the documentation
that these vfuncs need to chain up.
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
Tests currently fail under macOS because the tool claims not to work
on apple devices. Since I cannot disprove this myself, I'm disabling the
tests on Darwin.
As per the desktop entry specification, the `%k` field code should be
expanded to the location of the desktop entry file being processed. This
is only possible if the constructor-only filename property is populated,
which does not happen when using g_desktop_app_info_new_from_keyfile().
Moreover, since the Path directive in a desktop entry can be used to
set the working directory for the program to be launched, the location
passed as argument to the program must be modified such that it points
at the correct file when interpreted by the launched program. The
simplest way to achieve this consistently is to pass an absolute path.
However, g_desktop_app_info_new_from_keyfile() does not indicate why it
fails when it does. Because the tool aims to indicate whether launching
failed due to a missing file or a malformed one we first check this with
g_key_file_load_from_file().
This introduces an integration test that executes gio launch from a
variety of working directories, and checks that %k is expanded to a
location that makes sense in the context of the executed program, i.e.
an absolute path.
`g_file_enumerator_finalize` should not call `g_file_enumerator_close`
because object parts (i.e. subclass variable and/or resources) might
already be freed, causing memory safety issues.
A better place to call `g_file_enumerator_close` is
`g_file_enumerator_dispose` because it is safe to access the object
memory here.
Fixes#3713
Signed-off-by: fbrouille <150549-fbrouille@users.noreply.gitlab.gnome.org>
Each enumerated address can be of a different family type, so you have to make a socket after you have that information.
As this is just a test client we make a new socket each time for simplicity.
g-ir-scanner won't pick Since or Deprecated annotations if they are
inlined, they need a dedicated documentation block for this to work. The
since annotation is used, e.g. in gtk-rs, to not expose enum flags if
not compiled declaring we have a new enough glib version.
Verify that you can delete the file from the trash before moving it, if
the file is a directory owned by the user, recursively check for
non-empty directory not owned by he user.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1665
This works around a Meson bug
(https://github.com/mesonbuild/meson/issues/4668).
If we have a Python test which spawns a built native binary, that binary is
listed in the `depends` argument of the `test()`. On Linux, this results in
the directories containing the built libraries which the binary depends on
being added to the `LD_LIBRARY_PATH` of the test invocation. On Windows,
however, Meson currently doesn’t add those directories to `PATH` (which is
the equivalent of `LD_LIBRARY_PATH`), so we have to do it manually.
This takes the same approach as Christoph Reiter did in
gobject-introspection
(13e8c7ff80/tests/meson.build (L2)).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Unlike the previous commit, there is no `g_fdopen()` wrapper where we
can add cross-platform support for this.
I’m not adding that now just for `O_CLOEXEC` support for these two
calls, so pass the flag locally for now.
If someone wanted to add a `g_fdopen()` wrapper in future, the
`GLIB_FD_CLOEXEC` here could be refactored easily.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This adds cross-platform support for it: on glibc, musl and BSD’s libc,
the flag is natively supported. On Windows, convert it to the `N` flag,
which similarly indicates that an open file shouldn’t be inherited by
child processes.
This allows us to unconditionally pass `e` to `g_fopen()` so `O_CLOEXEC`
can easily be set on its FDs.
Also do the same for `g_freopen()`, since it shares the same underlying
mode handling code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Some apps names or keywords contain multiple words. For example 'LibreOffice
Calc' contains the word 'Calc'. This is rightfully detected as a prefix match,
however generally it is expected that searching for 'calc' would consistantly
return 'Calculator' in first position, instead of ranking them equally.
We now prioritise tokens that would otherwise rank equal based on where they
occur in the string, giving earlier occurences precedence.
