composition: Release objects lock while forwarding an event

There is no reason to keep it and in some rare cases it creates
deadlocks as followed:
  t1:
     → Composition receives a flushing seek, it takes the OBJECTS_LOCK
        and fowards the flushing seek event upstream
     → adder receives the seek and set its collectpad to flushing
        This implies tacking STREAM_LOCK (collectpad)

  t2:
    → Collectpad has buffers ready, and has the STREAM_LOCK
    (collectpad) and is EOS, so it sends it downstream
    → The composition receives EOS, and needs to check if it is
    the actual EOS or not, thus need to take the OBJECTS_LOCK

This create a deadlock, and in the first stage, we did not need the
OBJECTS_LOCK to forward downstream the flushing seek, so do not take
it.

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

1 files changed, 4 insertions, 2 deletions

diff --git a/gnl/gnlcomposition.c b/gnl/gnlcomposition.c
index 928da24..5d55ae6 100644
--- a/gnl/gnlcomposition.c
+++ b/gnl/gnlcomposition.c
@@ -1210,14 +1210,16 @@ gnl_composition_event_handler (GstPad * ghostpad, GstObject * parent,
      * event. In the case of seeks the pipeline will already be correctly
      * configured at this point*/
     if (priv->waitingpads == 0) {
+      COMP_OBJECTS_UNLOCK (comp);
       GST_DEBUG_OBJECT (comp, "About to call gnl_event_pad_func()");
       res = priv->gnl_event_pad_func (priv->ghostpad, parent, event);
       priv->reset_time = FALSE;
       GST_DEBUG_OBJECT (comp, "Done calling gnl_event_pad_func() %d", res);
-    } else
+    } else {
+      COMP_OBJECTS_UNLOCK (comp);
       gst_event_unref (event);
+    }
 
-    COMP_OBJECTS_UNLOCK (comp);
   }
 
 beach: