aggregator: don't hold stream lock when flushing
authorMathieu Duponchelle <mathieu@centricular.com>
Mon, 10 Jun 2019 15:23:29 +0000 (17:23 +0200)
committerMathieu Duponchelle <mathieu@centricular.com>
Mon, 10 Jun 2019 21:04:31 +0000 (23:04 +0200)
Releasing a GRecMutex from a different thread is undefined
behaviour.

There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.

I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.

libs/gst/base/gstaggregator.c

index a5b2860..98dbb14 100644 (file)
@@ -1335,10 +1335,6 @@ gst_aggregator_flush_start (GstAggregator * self, GstAggregatorPad * aggpad,
     GST_INFO_OBJECT (self, "Flushing, pausing srcpad task");
     gst_aggregator_stop_srcpad_task (self, event);
 
-    GST_INFO_OBJECT (self, "Getting STREAM_LOCK while flushing");
-    GST_PAD_STREAM_LOCK (self->srcpad);
-    GST_LOG_OBJECT (self, "GOT STREAM_LOCK");
-
     event = NULL;
   } else {
     gst_event_unref (event);
@@ -1436,9 +1432,7 @@ gst_aggregator_default_sink_event (GstAggregator * self,
         SRC_BROADCAST (self);
         SRC_UNLOCK (self);
 
-        GST_INFO_OBJECT (self,
-            "Flush stopped, releasing source pad STREAM_LOCK");
-        GST_PAD_STREAM_UNLOCK (self->srcpad);
+        GST_INFO_OBJECT (self, "Flush stopped");
 
         gst_aggregator_start_srcpad_task (self);
       } else {