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 ?) ?