The hash table used exclusively for looking up types by name used to map
quarks => types. But we can easily make it map strings => types, which
avoids the quark lookup. And that in trun avoids taking a lock and
consulting another hash table. So this change should make
g_type_from_name() roughly twice as fast.
When loading a keyfile the incoming bytes are fed
to a line buffer to get parsed each time a new line
is encountered.
The code that fills the line buffer does it inefficiently,
one byte at a time.
This commit changes that code to look ahead at the incoming
bytes for the next '\n' character and then fill the line buffer
all at once.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
When loading a key file, the keys and values of individual lines
are allocated once when copied and trimmed from the parse buffer
and allocated/copied again when added to the lookup map.
This commit avoids the second pair of allocations by introducing
a new function g_key_file_add_key_value_pair that gives the
lookup map direct ownership of the key and value copied from the
parse buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650211
For example, if setting a property on a skeleton from another thread
than where it was constructed, the idle handler responsible for
emitting the PropertiesChanged() signal could run immediately and
clear skeleton->priv->changed_properties_idle_source causing
g_source_unref() to be called with a NULL pointer. This race was
easily be fixed by adding a lock to the skeleton object.
In addition to fixing this race, also move the code for setting up the
idle handler to a class handler for the GObject::notify signal. This
change allows use of g_object_freeze_notify() and g_object_thaw_notify()
to perform atomic property changes from another thread than the one
that the skeleton was created in.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't drop resets from a GDelayedSettingsBackend when the writability
changes. Resets will always succeed, even against non-writable keys and
some people (gnome-screensaver) are using them in a way that they would
want them not to be forgotten.
This can easily happen if the owner of the remote object vanishes. Of
course, when that happens, user code is already notified (by e.g. the
notify::g-name-owner signal) so it can avoid using the proxy but
requiring that is a bit harsh. IOW, before this patch this critical
error was printed
GLib-GIO-CRITICAL **: g_dbus_gvariant_to_gvalue: assertion `value != NULL' failed
when that happened. With this patch, we just avoid setting the GValue
so the user will get the default value for its type instead. So, for
example, if the user code is getting a GVariant property on such a
defunct proxy, then he gets a NULL back. So unless said user code
checks the return value, criticals will still be printed if the NULL
GVariant is used for anything interesting.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Make g_date_time_format() support some useful format modifiers from
strftime(). This commit adds support for the POSIX 'O' modifier
(alternative digits), as well as the -/_/0 padding modifiers, which
are a GNU strftime() extension.
https://bugzilla.gnome.org/show_bug.cgi?id=648678
The code generator sprinkles a few asserts in its output of the form:
g_assert (prop_id - 1 >= 0 && prop_id - 1 < %d);\n
prop_id is unsigned, though, so this generates a compiler warning for
me.
This commit changes the code to merely check for prop_id != 0 instead of
prop_id - 1 >= 0
g_variant_new_string() hits a g_return_if_fail() when given invalid
UTF-8. That's certainly the right thing to do, but
g_variant_builder_add() uses this function internally and crashes when
it returns NULL due to the user passing a non-utf8 string.
We can protect the internal code by returning "[Invalid UTF-8]" in this
case while also making the problem easier to debug (and less fatal).
Closes#632631.
