mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-07-04 21:55:55 +00:00
Code Issues 1 Projects Releases Wiki Activity

queue: fix race when flush-stop event comes in whilst shutting down

Browse source 
Don't re-start the queue push task on the source pad when a
flush-stop event comes in and we're in the process of shutting
down, otherwise that task will never be stopped again.

When the element is set to READY state, the pads get de-activated.
The source pad gets deactivated before the queue's own activate_mode
function on the source pads gets called (which will stop the thread),
so checking whether the pad is active before re-starting the task on
receiving flush-stop should be fine. The problem would happen when the
flush-stop handler was called just after the queue's activate mode
function had stopped the task.

Spotted and debugged by Linus Svensson <linux.svensson@axis.com>

https://bugzilla.gnome.org/show_bug.cgi?id=734688
This commit is contained in:
Tim-Philipp Müller 2014-08-21 14:02:16 +01:00
parent ffa14610ca
commit 902a5e6bdc
1 changed files with 7 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
plugins/elements/gstqueue.c
View file

@ -792,8 +792,13 @@ gst_queue_handle_sink_event (GstPad * pad, GstObject * parent, GstEvent * event)
queue->srcresult = GST_FLOW_OK;
queue->eos = FALSE;
queue->unexpected = FALSE;
gst_pad_start_task (queue->srcpad, (GstTaskFunction) gst_queue_loop,
queue->srcpad, NULL);
if (gst_pad_is_active (queue->srcpad)) {
gst_pad_start_task (queue->srcpad, (GstTaskFunction) gst_queue_loop,
queue->srcpad, NULL);
} else {
GST_INFO_OBJECT (queue->srcpad, "not re-starting task on srcpad, "
"pad not active any longer");
}
GST_QUEUE_MUTEX_UNLOCK (queue);
STATUS (queue, pad, "after flush");