autoconf 2.68 is very insistent that AC_LANG_SOURCE/AC_LANG_PROGRAM
must be used in certain places, to avoid quoting/lack-of-quoting
problems, or something. Fix.
g_thread_init() causes a hash table to be allocated (in read_aliases).
Since hash tables are now a bit larger, we need to bump one of the
probe sizes to avoid our probe slice being used for the aliases
hash table.
Make hash tables start out in a mode in which they don't store
values at all, until the first insertion of a non-identical
key-value pair.
This reduces memory requirements by 1/3 when using hash tables
to store sets.
Based on a patch by Morten Welinder,
https://bugzilla.gnome.org/show_bug.cgi?id=644437
Kill g_hash_table_lookup_node and rename g_hash_table_lookup_node_for_insertion
to g_hash_table_lookup_node. Since at this point we already check for
toombstones in all callers of g_hash_table_lookup_node this doesn't make
a difference.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
This reduces memory requirements by 1/6 on 64-bit machines since
no padding is needed. It also puts less strain on the memory
allocator since we no longer need one giant slab of memory.
https://bugzilla.gnome.org/show_bug.cgi?id=644437
On Linux with gdb, it's much more convenient to debug programs using
G_DEBUG=fatal-warnings if we send SIGTRAP instead of abort() by
default. The default handler for both is to terminate the process.
In particular this makes it more easily possible to debug a warning
that's not the first in a program; you can skip past it and
go to the warning you care about.
The "aborting..." message is removed since it's no longer accurate,
and anyways was never very useful; crashes should show up in ABRT/apport
type crash catching systems.
https://bugzilla.gnome.org/show_bug.cgi?id=648423
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
GDesktopAppInfo violates the GObject rule that your C constructors
should just be thin wrappers around g_object_new(). While GKeyFile
isn't introspctable, this patch allows from JavaScript:
var app = new Gio.DesktopAppInfo({ filename: '/path/to/foo.desktop' });
https://bugzilla.gnome.org/show_bug.cgi?id=648425
When an old pre-thread-default-context API that takes an explicit
GMainContext wants to call a gio API, it must call
g_main_context_push_thread_default() before, and
g_main_context_pop_thread_default() after the gio call, so that the
gio method will return its result to the desired GMainContext.
But this fails for methods like g_socket_client_connect_async() that
make a chain of multiple async calls, since the pushed/popped context
will only affect the initial call.
Fix this by having GSimpleAsyncResult itself push/pop the context
around the callback invocation, so that if the callback queues another
async request, it will stay in the same context as the original one.
https://bugzilla.gnome.org/show_bug.cgi?id=646957
