[Bug 773463] core(debug): hard to distinguish related log at multi-instance env

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773463

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #351634|none                        |reviewed
             status|                            |

--- Comment #25 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
Comment on attachment 351634
  --> https://bugzilla.gnome.org/attachment.cgi?id=351634
info: Give more control to users about how to print objects

Again, only a quick look. I have some smaller nitpicks, but mostly questions
about thread-safety in two bits of code:

>+gchar *
>+_priv_gst_object_get_repr (GstObject * self)
>+{
>+    ...
>+    gst_object_replace (&parent, self->parent);

Why use gst_object_replace() here? Is this thread-safe? self->parent can only
be set once, but it's not clear to me that the underlying get+ref here is
really thread-safe when it's synchronised with the OBJECT_LOCK in set_parent().
But of course we can't take the lock here, can we?


>+void
>+_priv_gst_object_update_repr (GstObject * self, GstObject * parent)
>+{
>+  ...
>+  last_repr = gst_object_repr_ref (self->priv->repr);
>+
>+    /* If we deal with an always child object, we just need to make
>+     * sure its representation name is always in sync */
>+    g_free (last_repr->name);
>+    last_repr->unowned_name = NULL;
>+    last_repr->name = g_strdup (GST_STR_NULL (self->name));

Is this thread-safe? Might not some other thread also have an ObjRepr and be
accessing these strings in the other thread while we're changing them here? Or
do we not have to worry about that?


Then this in _update_repr():

>+  gst_mini_object_replace ((GstMiniObject **) & priv->repr,
>+      (GstMiniObject *) repr);

combined with this in _get_repr():

+  repr = gst_object_repr_ref (priv->repr);

Is this thread-safe? It's not an atomic read, and even if it was, couldn't some
other thread replace+unref+free the repr between our atomic read and the ref?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.