Similar to g_ref_*, we have g_atomic_ref_*, which will ensure that all
reference counting operations are performed atomically.
Not every data structure needs atomic reference counting; for instance,
most of the GTK+ data structures operate under the assumption that only
one thread can access windowing system data. Since atomic operations are
not cheap, forcing them on every data structure can negatively affect
performance.
The underlying reference counting mechanism for g_atomic_ref_* is the
same as for g_ref_*, but instead of adding a "make this atomic" boolean
flag to the g_ref_* API we prefer being explicit, and add the "atomic"
qualifier directly into the API, to avoid misunderstandings.
A common pattern inside GLib, and the rest of the G* platform, consists
of allocating some structure with a reference count. Usually, this
structure is hidden, but in some cases reference counting can be bolted
on top of public plain old data structures, or on top of existing C
types, like a char array.
If the data structure that needs reference counting is public we usually
"box" it into a reference counted container. Unfortunately, since we're
limited by the C syntax, this either means constantly de-referencing the
contents of the box in order to get to the real type; or it means
duplicating the whole API dealing with that type.
The alternative is to make the "box" transparent, and hide the reference
counting mechanism behind the pointer to the contents, using the same
mechanism GObject employs to handle private instance data.
This allows us to allocate some memory for a data structure and use it
in the same way we normally would with memory allocated via the system
allocator. Whenever we need to operate on the reference count of the
data, though, we reach behind the pointer and access the real reference
counted box.
Various data structures provided by GLib are reference counted, these
days, and each one of them implements its own reference counter. This
also happens to data structures implemented on top of GLib ones.
GLib should provide some common API to deal with reference counting —
both atomic and non-atomic. This way we keep the code duplication at a
minimum, while also providing guarantees of how reference counting
should work.
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
g_assert() gets completely compiled out if G_DISABLE_ASSERT is defined,
so applications should not depend on side effects of the expression in
an assertion.
Clarify that the arguments parameter can be zero if the function being
annotated just accepts a string format argument, and no varargs for it
(for example, if it takes a va_list of arguments instead).
Add some links to the GCC documentation for the `format` attribute.
This is to allow specification of the baseline Visual Studio 201x version as
the baseline version may not be 2010 anymore as we begin to require C99
features that will require Visual Studio 2013 or later.
We are starting to require C99 features that can only be supported in
Visual Studio 2013 and later, so we need to prepare rules for Visual Studio
2013 to be our baseline version for Visual Studio builds, so that we can
move the templates from Visual Studio 2010 to Visual Studio 2013.
As this strives to be a shared autotools module between projects, there is
duplication at this point, though, because we still want to support
2008~2012 for projects that do not yet require the C99 features and depends
on GLib-2.50.x/GTK+-3.22.x or earlier.
This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
So that we don't get "deprecation" (availability) warnings for
new functionality of GLib 2.51/2.52.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
I'm guessing the developments were done in 2.44 but the patches landed
after the 2.45.0 bump without an update to the Since tags.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769630
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
