Job names in gitlab pipeline view gets truncated to "fedora-meson-..."
for all jobs which is not really useful. All our CIs are using Meson,
and the host distro is not relevant when doing cross builds.
We should be testing latest NDK release but keep using API level 21 to
ensure GLib does not start using newer APIs. We could also later add a
runner for latest API level 28 which includes iconv API in Android's
libc so we don't need GNU libiconv anymore.
This reverts commit 03c324c64a and fixes
the original problem with e004d5f397 that
caused the revert.
We use $(builddir) instead of $(abs_builddir) so that Automake's
dependency generation works correctly.
See !127.
G_SPAWN_LEAVE_DESCRIPTORS_OPEN must be set to enable the optimized
posix_spawn codepath, so this flag is likely to see more usage now.
Document that FD_CLOEXEC can be used to cause file descriptors to be
automatically closed while this flag is used.
Add an app-launching function which allows standard file descriptors
to be passed to the child process.
This will be used by gnome-shell to pass systemd journal descriptors
as stdout/stderr. gnome-shell's child_setup function can then be
eliminated, which will enable use of the posix_spawn optimized
gspawn codepath for desktop app launching.
In order to use the new posix_spawn gspawn codepath, for more robust
app launching when available memory is low, we need to meet some
conditions.
child_setup needs to be NULL for this optimization to work, so drop
the internal child_setup that is used here. Replace it with a lightweight
wrapper binary (gio-launch-desktop) that sets GIO_LAUNCHED_DESKTOP_FILE_PID
before executing the app.
Adjust PATH for gio tests so that it can execute the new binary from the
build directory.
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen.
In this case we are simply calling fork() in order to quickly call exec(),
which will throw away the entirity of the duplicated VM, so we should
look for ways to avoid the overcommit check.
The well known solution to this is to use clone(CLONE_VM) or vfork(), which
completely avoids creating a new memory address space for the child.
However, that comes with a bunch of caveats and complications:
https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234https://ewontfix.com/7/
In 2016, glibc's posix_spawn() was rewritten to use this approach
while also resolving the concerns.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9ff72da471a509a8c19791efe469f47fa6977410
I experimented with a similar approach in glib, but it was not practical
because glibc has several items of important internal knowledge (such as
knowing which signals should be given special treatment because they are
NPTL implementation details) that are not cleanly exposed elsewhere.
Instead, this patch adapts the gspawn code to use posix_spawn() where
possible, which will reap the benefits of that implementation.
The posix_spawn API is more limited than the gspawn API though,
partly due to natural limitations of using CLONE_VM, so the posix_spawn
path is added as a separate codepath which is only executed when the
conditions are right. Callers such as gnome-shell will have to be modified
to meet these conditions, such as not having a child_setup function.
In addition to allowing for the gnome-shell "Cannot allocate memory"
failure to be avoided, this should result in a general speedup in this
area, because fork()'s behaviour of cloning the entire VM space
has a cost which is now avoided. posix_spawn() has also recently
been optimized on OpenSolaris as the most performant way to spawn
a child process.
Add a new process spawning function variant which allows the caller
to pass specific file descriptors for stdin, stdout and stderr.
It is otherwise identical to g_spawn_async_with_pipes.
Allow the same fd to be passed in multiple parameters. To make this
workable, the child process logic that closes the fd after the first time
it has been dup2'ed needed tweaking; we now just set those fds to be
closed upon exec using the CLOEXEC flag. Add a test for this case.
This will be used by gnome-shell to avoid performing equivalent
dup2 actions in a child_setup function. Dropping use of child_setup will
enable use of an upcoming optimized process spawning codepath.
Nevertheless it accepts "w+b".
When checking the Win32 documentation of fopen()/_wfopen(), it clearly
states:
> In addition to the earlier values, the following characters can be
> appended to mode to specify the translation mode for newline
> characters.
This implementation expects 'b' or 't' to be appended, and therefore
"wb+" ends up with an error, whereas the alias "w+b" works perfectly
while it is exactly the same thing. So let's just have glib "translate"
the mode when it can to have it working transparently the same way on
every platform.
Using g_assert_cmpfloat() with a float or double causes warnings on the
newest Clang version, because the macro internally promotes all values to
a long double, which Clang warns about. Casting explicitly removes the
warning.
Closes: #1377
This makes them a bit more unique (and, crucially, in the g_* namespace)
to avoid shadowing collisions with calling code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/258
They’re network file systems, but not system file systems (in the sense
that procfs is a system file system). This fixes them disappearing from
the sidebar in the UI.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1424
This commit adds two W32-only environmental variable checks:
* G_WIN32_ALLOC_CONSOLE, if set to 1, will force glib to create
a new console if the process has no console by itself.
This option is for GUI apps that are launched from GUI
processes, in which case there's no console anywhere near them.
* G_WIN32_ATTACH_CONSOLE, if set to a comma-separated list of
standard stream names (stdint, stdout, stderr), will reopen
a given std stream and tie it to the console (using existing console
or parent console).
This works either with the other option (to create a console),
or if the app is launched from a console process (often the
case for developers).
The redirection is done with freopen(), dup() and dup2().
If everything goes well, C file descriptors 0, 1 or 2 will
be bound to stdin, stdout and stderr respectively (only for
streams listed in the envrionmental variable), and so will
be stdio streams by the same names.
With these it's possible to see the output of g_log*() functions
when running GTK4 applications, which are linked as GUI applications,
and thus do not get a console by default.
https://bugzilla.gnome.org/show_bug.cgi?id=790857
Fixes issue #1304
Add a new syntax to override files: if the group name has a ':' in it,
it indicates that we want to override the default values of keys for
only one desktop. For example:
[org.gnome.desktop.interface:Unity]
font-name='Ubuntu 12'
Will override the settings, only if "Unity" is found in
XDG_CURRENT_DESKTOP. Multiple per-desktop overrides can be specified
for a given key: the one which comes first in XDG_CURRENT_DESKTOP will
be used.
https://bugzilla.gnome.org/show_bug.cgi?id=746592
Recognise a new 'd' option in schema keys which gives a dictionary of
per-desktop default values. This dictionary is searched for the items
found in XDG_CURRENT_DESKTOP, in the order. If nothing matches (or if
the option is missing) then the default value is used as before.
This feature was requested by Alberts Muktupāvels and this patch is
based on an approach devised by them.
https://bugzilla.gnome.org/show_bug.cgi?id=746592
There are a couple of different ways (and soon one more) to access the
default value of a key. Clean up the various places that access this to
avoid duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=746592
There were previously no tests for it. These take gmountoperation.c up
to 85.5% coverage of lines.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1423
check_expected_events is heavily modified in this commit to tolerate
event loss and allow renaming to be reported as creation and deletion.
This fixes test failure on FreeBSD.
Previously, kqueue file monitor only add event sources for directories
regardless of the type of the file being monitored. Doing so may be
possible on inotify, but it is not sufficient on kqueue. Watching a
directory on kqueue doesn't report changes made to files under it, and
we must watch files themselves to get notified. This problem is fixed
by adding a second watch for non-directory file monitors, and the result
is that we are now able to receive 'CHANGED' and 'ATTRIBUTE_CHANGED'
events for non-directory files.
Since having two watches on one file monitor requires many code changes
to work properly, this commit also changes the following things:
- NOTE_ALL macro is now replaced by note_all inline function. Since the
kqueue backend is shared by all BSD operating systems, there are a
few difference between these systems. It is easier to do '#ifdef'
check in a function than in a macro.
- Both g_kqueue_file_monitor_callback and g_kqueue_file_monitor_cancel
now holds a lock before accessing kqueue_sub structs. This fixes a
crash when these two functions are called from different threads,
causing g_kqueue_file_monitor_callback to access freed memory.
- 'mask' variable in g_kqueue_file_monitor_callback is now removed.
The usage of 'mask' was wrong because of the 'mask > 0' check.
'CHANGED' event has value 0 so the 'mask > 0' check made it
impossible to emit 'CHANGED' events.
- kqueue-missing scans can now be triggered from the kqueue event
callback instead of always waiting for 4 seconds.
- Don't remove a file from kqueue on unlink unless its hard link count
has dropped to zero.
- Don't use 'else if' in the check of 'fflags'. It is possible for a
kevent to have multiple flags set.
- Don't use g_file_monitor_emit_event directly. Always use
g_file_monitor_source_handle_event to report events.
Events submitted to g_file_monitor_emit_event are delivered
immediately, but events sent to g_file_monitor_source_handle_event
are scheduled by GLocalFileMonitor. If we mix the two, the order of
events will be wrong and tests will fail.
- Report 'CHANGES_DONE_HINT' immediately after 'CREATED' if the file
created is not a regular file. This is copied from ih_event_callback.
This function only calls fsync() if @target exists and is non-empty. If
not, it doesn't provide the "old contents or new contents" guarantee
that one might expect. This has been the case since
d20a188b12, and is justified either as a
performance optimization or by asserting that this function only
guarantees to not destroy existing data (implicitly defining
non-existence or emptiness as not data).
In addition, explicitly spell out that whether it's atomic in the
non-empty case is system-dependent. If the system administrator has
configured some funky filesystem options, they may be out of luck on the
atomicity front.
https://gitlab.gnome.org/GNOME/glib/issues/1302
