Generate a deprecation notice in the `--help` output for deprecated
options. This helps with the documentation of command line utilities.
Put the deprecation notice near the argument, to allow application
developers to add a notice on the deprecation on their own, and
explain what to use instead.
We don't allow unloading types, both static and dynamic, since 2013. The
code that deals with reference counting is mostly dead code, and makes
reasoning about the type system more complicated than necessary.
Since type classes and interfaces can only be instantiated, we introduce
explicit getter functions that create a GTypeClass or a GTypeInterface
vtable; the ref() and unref() API gets a "soft" deprecation (explicitly
not using `GOBJECT_DEPRECATED_IN_*` yet), to allow people to
progressively port their code.
A new header check is added for non-standard <sys/ucred.h>. Some platforms, like Linux, might support <sys/param.h>, <sys/mount.h>, and <fstab.h> but not this. Which can cause compilation to fail for gio/gunixmounts.c
This request brings support to the latest version of QNX software. _g_get_unix_mount_points (void) for getfsent() system also works on QNX. To avoid duplicating codes, it will be reused.
wiki.gnome.org has been retired but for some reason none of the old
pages were given HTTP redirects, so everyone has to update all their
links manually everywhere.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This makes the documentation for this function more consistent with that
of g_ptr_array_unref(), which makes it clear that it acts like
g_(ptr_)array_free with free_segment=TRUE.
Port the rest of the document to gi-docgen syntax, so we don’t have to
track partially-ported files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
GData is a thread safe container. For that reason, it probably is anyway
not suitable to add 4 billion entries. That is even with the new index,
where we now scale with O(1).
Still, the code should not just break down at half of what we
theoretically could add.
Handle overflow and huge sizes correctly.
g_datalist_get_data() tries to avoid g_quark_try_string() and instead
do the lock-less g_quark_to_string(). For small number of entries that
may perform better. At least, this was an optimization from the past.
However, if we have a GHashTable index, and presumably a larger number
of entries, we should use the index instead. Unfortunately, that requires
us again to use g_quark_try_string() and take a global lock.
GData tracks the entries in a linear array, and performs a linear
search. That is very good, as long as the number of entries is small.
However, when it grows, performance gets worse. It's not clear what the
exact threshold is, or what the recommended maximum is.
Also, GData is used to attach arbitrary user data to GObject. Which is a
great feature, that a user might want to use. In that case, they may be
less concerned about performance to get the benefits of the feature, and
thus add more data than is best (though, it's unclear how much is too
much).
Also, GObject adds entries in its qdata. Hence, also for basic GObject
operations, it's important that this performs well. Note that access to
GData happens while holding a lock, we want to minimize the time while
holding that lock.
This patch ensures that access to GData is O(1) (and reasonably fast).
It thus allows to use GData in ways that wasn't advised previously.
There are alternatives, like using a binary search tree or always use a GHashTable.
Instead, we keep the linear buffer. Only when the buffer grows to
ALLOC_THRESHOLD_INDEX entries, we will start generating and maintaining
a GHashTable index. So the common case where objects have few entries
does not change. The memory overhead is only there, when the list grows.
ALLOC_THRESHOLD_INDEX is set to 64 entries. We will allocate such a
large buffer when adding the 33rd entry. During shrink, we will drop the
buffer again when shrinking down to 16 entries.
The reason for not always using the GHashTable is to save the memory in
common cases where there are few entries.
We use g_hash_table_add() to exploit the GHashTable optimization. We
also let it point to the GDataElt from the linear array. The benefit is
that we don't require individual allocations. The downside is that
during reallocation we need to regenerate the entire index.
In my tests this actually performs well. For example, following are
timings for calling g_dataset_id_get_data() in a loop. This is the
lookup time for an entry that doesn't exist. Obviously, the linear
search would scale always best when we would only lookup the first entry
in the list.
num-entries time-before time-after
1 0.144 0.145
2 0.146 0.146
5 0.149 0.150
10 0.155 0.157
20 0.172 0.170
32 0.248 0.254
33 0.249 0.184 <== index in use
40 0.284 0.183
50 0.317 0.189
75 0.370 0.184
100 0.442 0.183
300 1.044 0.186
1000 3.170 0.184
10000 31.597 0.189
This will be more useful next.
Also, try to detect whether realloc() actually moved the pointer. If it
doesn't, we can optimize a bit (not use g_datalist_unlock_and_set()).
Next, we will do more useful optimization in this case.
Note that we cannot just compare dangling pointers. That's would be
undefined behavior. In practice, we probably often compare dangling
pointers, and this tends to work just fine. Still avoid this and compare
only the guintptr values.
Avoid duplicated code.
Also, the "if (data->data[i].data && " check is unnecessary. The data
pointer is never NULL, because g_datalist_id_set_data() will treat that
as indication to remove the entry.
The #if condition as-written fails for any major >= 5 if minor < 3, e.g.
GCC 14.2 and so on.
Use the idiom described in the GCC docs [0] to avoid this.
[0] https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
Fixes: 57878d6042366070e80a109bf113ac03abb86cfd
