[Bug 734688] gsttask: Deadlock when running gst_task_join()

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=734688
  GStreamer | gstreamer (core) | git

--- Comment #15 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-08-21 13:10:14 UTC ---
Created an attachment (id=284082)
 View: https://bugzilla.gnome.org/attachment.cgi?id=284082
 Review: https://bugzilla.gnome.org/review?bug=734688&attachment=284082

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

How about this?

    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
    receving 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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.