luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2025-02-09 12:25:48 +01:00
Code Issues Packages Projects Releases Wiki Activity

build: Migrate G_ATOMIC_LOCK_FREE docs from configure.ac to meson.build

Browse Source 
The explanation of how G_ATOMIC_LOCK_FREE is meant to be used is useful.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
This commit is contained in:
Philip Withnall 2018-05-22 09:48:04 +01:00
parent 3c9a7ec270
commit c16e8af351
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
meson.build
View File

@ -1434,6 +1434,19 @@ else
endif endif
glibconfig_conf.set('G_ATOMIC_OP_MEMORY_BARRIER_NEEDED', glib_memory_barrier_needed) glibconfig_conf.set('G_ATOMIC_OP_MEMORY_BARRIER_NEEDED', glib_memory_barrier_needed)
# We need to decide at configure time if GLib will use real atomic
# operations ("lock free") or emulated ones with a mutex. This is
# because we must put this information in glibconfig.h so we know if
# it is safe or not to inline using compiler intrinsics directly from
# the header.
#
# We also publish the information via G_ATOMIC_LOCK_FREE in case the
# user is interested in knowing if they can use the atomic ops across
# processes.
#
# We can currently support the atomic ops natively when building GLib
# with recent versions of GCC or MSVC.
#
# Note that the atomic ops are only available with GCC on x86 when # Note that the atomic ops are only available with GCC on x86 when
# using -march=i486 or higher. If we detect that the atomic ops are # using -march=i486 or higher. If we detect that the atomic ops are
# not available but would be available given the right flags, we want # not available but would be available given the right flags, we want