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.
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
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
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
This fits better with the convention in the rest of GLib where arbitrary
8-bit values are represented as guint8, avoiding the potential confusing
of a name which references ‘char’s.
This is not an API break, as both guint8 and guchar are unconditionally
typedeffed to unsigned char.
https://gitlab.gnome.org/GNOME/glib/issues/896
There seems to be little point in substituting the version number into
README (using autotools). Rename it to README.md and distribute that
verbatim (with autotools and Meson) instead.
Autotools still requires that README exists, so leave a stub README file
in place which redirects people to README.md. This can be dropped when
we drop autotools support.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
GVfs utils used to have bash completion, which was pretty useful. However,
it hasn't been ported to gio tool unfortunately. GLib provides completion
for various utils already, so it would be nice to provide completion also
for gio tool. I've updated old bash completion code and merged with some
my old unmerged fixes.
The gvfs completion used "gvfs-ls --show-completions" helper. This mentioned
option hasn't been obviously ported to "gio list" and the proposed completion
doesn't add this option in "gio list" to not pollute the codes, but maybe it
is a bit slower as consequence.
The proposed bash completion suggests subcommands, uris and paths including
the remote mounts. It contains some workarounds, especially because of proper
handling of paths with colons and other special chars (like spaces)...
