gdbus-codegen: Ensure that generated skeletons are MT-safe

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>

docs/reference/gio/gdbus-codegen.xml

@@ -711,12 +711,17 @@ on_handle_hello_world (MyAppFrobber           *object,
     <para>
       To facilitate atomic changesets (multiple properties changing at
       the same time), #GObject::notify signals are queued up when
-      received. The queue is drained in an idle handler and will cause
-      emissions of the <ulink
+      received. The queue is drained in an idle handler (which is called from the
+      <link linkend="g-main-context-push-thread-default">thread-default main loop</link>
+      of the thread where the skeleton object was
+      contructed) and will cause emissions of the <ulink
       url="http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties">org.freedesktop.DBus.Properties::PropertiesChanged</ulink>
       signal with all the properties that have changed. Use
       g_dbus_interface_skeleton_flush() or
-      g_dbus_object_skeleton_flush() to empty the queue immediately.
+      g_dbus_object_skeleton_flush() to empty the queue
+      immediately. Use g_object_freeze_notify() and
+      g_object_thaw_notify() for atomic changesets if on a different
+      thread.
     </para>
   </refsect2>
 </refsect1>