The Linux eventfd() call is basically tailor made for the main loop
wake up pipe - all we want is a threadsafe way to write to a file
descriptor, and wake up the context on the other end; we don't care
about the content at all.
The eventfd manual page basically explains the benefits:
Applications can use an eventfd file descriptor instead of a
pipe (see pipe(2)) in all cases where a pipe is used simply to
signal events. The kernel overhead of an eventfd file
descriptor is much lower than that of a pipe, and only one file
descriptor is required (versus the two required for a pipe).
When writing my multithreaded spawn test case I actually hit the 1024
file descriptor limit quickly, because we used 2 fds per main context.
This brings that down to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=653140
There is no chance that an unsigned integer value will be negative after
we do the bounds check that enforces its non-negativity.
Caught by Matthias running Coverity.
Running gthread/tests/spawn-multithreaded in a loop, I very easily hit:
GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
Testing the refcount still left a window where we would fall into the
assertion. Fix this by just locking the context.
We should by default reset signal handlers; particularly with the
ability to install them via g_unix_signal_source_new(), we don't
want to call a user callback inside a fork()ed helper process.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
I was debugging gthread/tests/spawn-multithreaded.c, and while I
don't think I actually hit EINTR in any of these cases, it'd be
good to fix them anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=652072
asm goto was addded in gcc 4.5 so don't try to use it on gcc versions
older than this one. This is achieved by explicitly checking gcc
version, an alternative would be to try to compile a program using
asm volatile in configure.
https://bugzilla.gnome.org/show_bug.cgi?id=651959
Fix various (out) arguments, (allow-none) and (array zero-terminated=1)
for g_spawn_*() and some others.
Some additional fixes by Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646635
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
g_datalist_id_clear_i was dropping the dataset lock around
the destroy notifies, but kept the bitlock. This was causing
deadlocks when finalizing widgets.
