For some reason, the setting of g_atomic_lock_free wasn't making it down to the lower part of the configure script where glibconfig.h was being generated when building using mingw32-configure. If we prefix glib_cv_ to the start of the variable name (like everyone else is doing) then it magically starts working. I love you, automake.
We didn't previously test anything except the implicit default of TRUE. Now we test implicit TRUE, explicit TRUE, explicit FALSE, and disconnecting at the local end (which regressed while fixing Bug #651268). Also avoid some questionable use of a main context, which fell foul of Bug #658999 and caused this test to be disabled in master. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Bug-NB: NB#287088 Signed-off-by: Simon McVittie <email@example.com> Reviewed-by: David Zeuthen <firstname.lastname@example.org>
This was a regression caused by my previous work on GDBusWorker thread-safety (Bug #651268). The symptom is that if you disconnect a GDBusConnection locally, the default implementation of GDBusConnection::closed terminates your process, even though it shouldn't do that for locally-closed connections; this is because GDBusWorker didn't think a cancelled read was a local close. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Bug-NB: NB#287088 Signed-off-by: Simon McVittie <email@example.com> Reviewed-by: David Zeuthen <firstname.lastname@example.org>
pthreads doesn't implement the _lock_full() and _unlock_full() calls on recursive mutexes so we don't have it on GRecMutex either. Now that we're using GRecMutex to implement GStaticRecMutex, we have to fake it by keeping an internal counter of the number of locks and calling g_rec_mutex_unlock() the appropriate number of times. The code to do this looked like: depth = mutex->depth; while (mutex->depth--) g_rec_mutex_unlock (rm); return depth; which unfortunately did one last decrement after mutex->depth was already zero (leaving it equal to -1). When locked the next time, the count would then increase from -1 to 0 and then the next _unlock_full() call would not do any calls to g_rec_mutex_unlock(), leading to a deadlock. https://bugzilla.gnome.org/show_bug.cgi?id=661914
We clean up the detection of if we should do 'real' atomic operations or mutex-emulated ones with the introduction of a new (public) macro: G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to be done in hardware. We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our compiler supports GCC-style atomic operations from the gatomic.h header because we might be building a program against GLib using a different set of compiler options (or a different compiler) than was used to build GLib itself. Unfortunately, this macro is not available on clang, so it has currently regressed to using the mutex emulation. A bug about that has been opened here: http://llvm.org/bugs/show_bug.cgi?id=11174
This is needed to implement efficient and predictable proxy volume monitors, see https://bugzilla.gnome.org/show_bug.cgi?id=661711 for details. Signed-off-by: David Zeuthen <email@example.com>
GDBusConnection sets the closed flag in the worker thread, then adds an idle callback (which refs the Connection) to signal this in the main thread. The tests session_bus_down doesn't spin the mainloop, so the "closed" signal will always fire if iterating the mainloop later (and drops the ref when doing so). But _is_closed can return TRUE even before signalling this, in which case the "closed" signal isn't fired and the ref isn't dropped, causing the test to fail. Instead simply always wait for the closed signal, which is a good thing to check anyway and ensures the ref is closed. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896 Reviewed-by: Matthias Clasen <firstname.lastname@example.org>
Last commit was wrong, fixing it up
-gcharset.c, genviron.c, gunicollate.c: Some headers were missed in those files that triggered C4013 warnings/errors (aka. implicit declaration of ... in GCC). Make up for them here. -gwin32.h: Only define g_win32_get_package_installation_directory/ g_win32_get_package_installation_subdirectory as macros (alias of g_win32_get_package_installation_directory_utf8/ g_win32_get_package_installation_subdirectory_utf8) on Win64 (x64) as g_win32_get_package_installation_directory/ g_win32_get_package_installation_subdirectory have seperate existing implmentations for Win32-this is a long-standing problem but was covered- up by G_DISABLE_DEPRECATED, which we are stopping to use as of 2.31.0.
…olchain" This reverts commit 3492122.
Move filename-related functions to gfileutils, and move size formatting functions to gutils.