The functions with a GDestroyNotify to the data, or other ill-fitting
allocation semantics, are not currently introspectable.
The effect for the binding user would be that they're unable to
create or destroy a GData list, but they might still have an API
to poke at some data pointers from it.
In fact, none of the functions dealing with GData** or a dataset
location pointer are likely to get sensible bindings anyway;
the annotations added are mostly to avoid memory unsafety
and leaks.
https://bugzilla.gnome.org/show_bug.cgi?id=756470
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
This code is used in the property notification path, so it
better be fast. This commit removes a g_return_if_fail check and
treats the common case of just a single data element better.
Also, make it possible to get a 'new ref' on a datalist member
in a race-free way.
This is useful when using object data in thread-safe libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=682849
Removing the last thing in a dataset frees the dataset, and if the
datalist was in a dataset, we can't safely unlock it after the dataset
has been freed. Unlock it sooner.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666113
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
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.
Instead of converting the string to a quark and comparing quarks we
use the new lockless g_quark_to_string and just compare the quarks
in the datalist with the given string.
This means we avoid the global lock for string to quark. Additionally
most of the time the data list will be quite short, so the cost of
doing the sting comparisons is likely similar to that of the quark
hashtable lookup (which does at least one string comparison for a
successfull lookup).
https://bugzilla.gnome.org/show_bug.cgi?id=650458
We do this by assigning to g_quarks atomically and leaking it when
replacing it atomically. Then its safe to consume the array
on the reader side (atomically).
Also, since we're leaking quarks on growing, bump the block size
so that we're not leaking as much. gtk3-demo allocates > 1500 quarks,
and gnome apps > 3000. I'm setting the block to 2048 which means no
leaks for small gtk3 apps and just one leak for gnome apps.
https://bugzilla.gnome.org/show_bug.cgi?id=650458
This implementation uses a per-list bitlock for user data, and a
simple array rather than a linked list which uses less memory and less
allocations. It also gets better cache behaviour since related things
are stored close to each other.
https://bugzilla.gnome.org/show_bug.cgi?id=650458
This adds static markers for dtrace, which are also usable
by systemtap. Additionally it adds a tapset for systemtap
that makes it easier to use the static markers.
These are enabled by default.
This initial set of probes is rather limited:
* allocation and free using g_malloc & co
* allocation and free using g_slice
* gquark name tracking (useful for converting quarks to strings in probes)
Notes on naming:
Its traditional with dtrace to use probe names with dashes as
delimiter (slice-alloc). Since dashes are not usable in identifiers
the C code uses double underscores (slice__alloc) which is converted
to dashes in the UI. We follow this for the shared lowlevel probe
names.
Additionally dtrace supports putting a "provider" part in the probe
names which is essentially a namespacing thing. On systemtap this
field is currently ignored (but may be implemented in the future), but
this is not really a problem since in systemtap the probes are
specified by combining the solib file and the marker name, so there
can't really be name conflicts.
For the systemtap tapset highlevel probes we instead use names that
are systemtapish with single dashes as separators.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
GLib users buildable with gcc 4.4. Patch by Jakub Jelinek.
* glib/gatomic.[hc]: Add G_GNUC_MAY_ALIAS to pointer arguments,
fix macro versions to only operate on objects of the same size.
* glib/gdataset.c:
* glib/gthread.[hc]:
* glib/gdatasetprivate.h: Remove unnecessary casts in
g_atomic_pointer_get calls.
svn path=/trunk/; revision=7875
Tue Jan 31 16:45:03 2006 Tim Janik <timj@imendio.com>
* glib/gdataset.c: carry out all dtalist pointer accesses atomically,
some missing cases where pointed out by Sebastian Wilhelmi.
