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
We can use AC_CHECK_FUNCS to detect if qsort_r is available on
the system or not since it will unconditionnally define
HAVE_QSORT_R, which we don't want since on BSD, qsort_r isn't usable
for us, so we don't want to have HAVE_QSORT_R defined on such platforms.
By using AC_CHECK_FUNC instead, we can defer defining HAVE_QSORT_R until
we have actually tested it's usable.
https://bugzilla.gnome.org/show_bug.cgi?id=651920
When cross compiling, test programs cannot be run. In order to make it
easier to cross compile for targets that do not have qsort_r(), check
for the function before trying to run the test program.
This avoid having to populate cache with glib_cv_have_qsort_r=no with
e.g. mingw cross compiler.
https://bugzilla.gnome.org/show_bug.cgi?id=651920
This avoids the generated types (e.g. ExampleAnimal, ExampleCat,
ExampleObject and ExampleObjectManagerClient) being referenced in the
core gio docs. This was requested by Matthias.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Commit 22e7fc34c4 introduced a regression:
futexes were always disabled and the emulated codepath was always being
used. That commit was in response to an originally buggy
implementationt hat wrote junk into config.h (but happened to be working
properly).
Fix up the mess and while we're at it, close bug #631231 by including
syscall.h from the correct location and using __NR_futex instead of
SYS_futex.
Closes#631231.
When using gcc builtins for atomic operations, provide them
as macros, so gcc can see the builtins and do optimizations.
This change gives considerable speedups in bitlocks, which
use atomic operations heavily, see bug 650458.
Also, don't define G_ATOMIC_OP_MEMORY_BARRIER_NEEDED unconditionally
when using gcc builtins.
https://bugzilla.gnome.org/show_bug.cgi?id=617491
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
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.
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
Remove some code that was written in 2000 to support OSes that do not
have nanosleep(). nanosleep() has been specified (in POSIX-1.2001) for
almost a decade now, so assume we have it (except on Windows).
Remove the checks for nanosleep and nsleep from configure.ac.
We're removing this code because we honestly believe that nobody will be
affected. If this change negatively impacts you, please file a bug.
