The global hash table we use for interned strings should not own a
reference on the strings themselves, as otherwise we'd leak them all
over the place.
Instead, it should keep a "weak" reference to them; once the last
strong reference goes away, we drop remove the weak reference from the
hash table.
Both g_rc_box_release_full() and g_atomic_rc_box_release_full() should
allow passing NULL as the clear function, to conform to the existing
coding practices in GLib.
Additionally, this allows us to reimplement release() in terms of
release_full(), and improve test coverage.
The last part of the reference counting saga.
Now that we have:
- reference counter types
- reference counted allocations
we can finally add reference counted strings using reference counted
allocations to avoid creating a new String type, and reimplementing
every single string-based API.
It's more useful to have a dup() function that copies any blob of memory
into a reference counted allocation, than to have a dup() that only
copies a reference counted allocation.
GArcBox is the atomic reference counting version of GRcBox. Unlike
GRcBox, the reference acquisition and release on GArcBox are guaranteed
to be atomic, and thus they can be performed from different threads.
This is similar to Rust's Arc<Box<T>> combination of traits.
It is useful to provide a "reference counted allocation" API that can
add reference counting semantics to any memory allocation. This allows
turning data structures that usually are placed on the stack into memory
that can be placed on the heap without:
- adding a public reference count field
- implementing copy/free semantics
This mechanism is similar to Rust's Rc<Box<T>> combination of traits,
and uses a Valgrind-friendly overallocation mechanism to store the
reference count into a private data segment, like we do with GObject's
private instance data.
They’re all 8 bytes long, and integer constants that large need a suffix
on 32-bit platforms.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/977
Philip Withnall suggests that glib should treat all negative
file descriptors as unset/invalid, rather than explicitly requiring
them to be -1.
This can simplify the logic for some users of this code.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/132
It’s been de-facto deprecated for a long time, due to emitting a
critical warning when used in a non-internal context. Make that official
in the documentation and with a deprecation annotation.
Split the implementation into an internal helper and an external
wrapper, so the two remaining internal uses don’t emit deprecation
warnings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/903
For the purposes of debugging, it is quite useful for every GSource to
have a name set. Ensure that any GSource we construct inside GLib has a
name set. For GSources which are then returned to the caller, this name
can then be overridden with something even more useful by the caller.
Since this data is only used for debugging, avoid doing any allocations
for it; just use static strings.
https://gitlab.gnome.org/GNOME/glib/issues/1175
It’s good to know *which* GMainContext is used to determine the ID, and
the preconditions for calling this method.
Using wording suggested by Emmanuele Bassi <ebassi@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Function do_posix_spawn uses environ, but gspawn.c doesn't declare it.
Since there is no system header declaring this global variable, this
causes compilation error on FreeBSD.
Code added in this commit is copied from genviron.c.
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.
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 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
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
d20a188b1250ab3cf211d684429127d99378e886, 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
People do (and should) use g_str_equal() for string comparisons outside
of hash tables, because it’s easier to read than
`strcmp (str1, str2) == 0`. That should not be discouraged.
However, we should still be careful to point out that g_str_equal() is
not NULL-safe, and g_strcmp0() is.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
A slightly modified patch originally written by Morten Welinder
<terra@gnome.org> to make the error codes returned by g_spawn_*()
functions more specific when on Windows. They are already this specific
on Linux.
Add a unit test for the ENOENT case.
https://gitlab.gnome.org/GNOME/glib/issues/303
Signed-off-by: Philip Withnall <withnall@endlessm.com>
