This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
In the previous code, if the timezone was pulled out of the cache again
just as the last reference was being dropped, the cache code will
increase its refcount and return it while the unref code was freeing it.
Protect against that.
Closes#646435.
g_tls_certificate_list_new_from_file() was leaking the file contents,
and GSource was leaking the GSourcePrivate structure that got
created when using child sources.
We really shouldn't use <unknown> when we can perfectly easily
get argv0 out of /proc. This avoids people having to pass argv
down into gtk_init/g_option_context_parse etc., which is important
because GTK+ uses it to initialize the WM_CLASS, which in turn
GNOME Shell consumes for application tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=644309
Add a new function that allows the parser to check that the current
token is equal to a given string without consuming the token.
Reimplement the 'consume' function in terms of the new function.
Robert Ancell discovered that the GVariant parser messes up pretty badly
when the type of a tuple is specified and the tuple in the text being
parsed has a different number of elements (but otherwise matching child
types).
Check that we have the expected number of elements.
Closes#644786.
* Since the GLib translations are lazily initialized, we need an
internal wrapper for g_dpgettext() that does the initialization
in the same way as glib_gettext()
* We need to use the glib domain defined by GETTEXT_PACKAGE
rather than than the application's domain.
https://bugzilla.gnome.org/show_bug.cgi?id=644607
