[Bug 751637] New: Pull mode element downstream hogs the pad stream lock

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 751637
           Summary: Pull mode element downstream hogs the pad stream lock
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: vincent.penquerch at collabora.co.uk
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

With the example pipeline:

filesrc ! wavparse ! fakesink

wavparse will switch to pull mode, and create a pad task which will pull till
EOS. The pad task calls:

task->func (task->user_data);

in a loop, while holding the pad stream lock, which is therefore not released
at all until the element goes flushing, stops, etc.

While this goes on, if there is a event going downstream that reaches wavparse
(eg, sink-message), the gstpad.c code will lock the stream lock before pushing
the event. It will then wait an arbitrary long time before being able to do so.

This proof of concept:

diff --git a/gst/gsttask.c b/gst/gsttask.c
index d9e5697..47d3e6f 100644
--- a/gst/gsttask.c
+++ b/gst/gsttask.c
@@ -329,6 +329,11 @@ gst_task_func (GstTask * task)
     }

     task->func (task->user_data);
+
+    /* Allow something else to use the lock. Still a lot of contention though
*/
+    g_rec_mutex_unlock (lock);
+g_usleep (1000);
+    g_rec_mutex_lock (lock);
   }

   g_rec_mutex_unlock (lock);

shows that this is indeed the problem, as my code works as expected with this
bodge in.

There doesn't seem to be any reason why the lock can't be released between
calls to the pad task function. A possible fix for this would be passing a
condition variable along with the lock, but this would need changing a
substantial amount of elements.

Any better way to fix ? Or is this as intended, and the lock really should not
be released (why, then ?) ?

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