GNOME Bugzilla – Bug 751637
Pull mode element downstream hogs the pad stream lock
Last modified: 2018-11-03 12:28:13 UTC
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 ?) ?
Indeed, I can confirm this behavior in 1.12. It seems impossible to push a downstream serialized event externally (via gst_element_send_event on the pipeline) when the source element is in pull mode. Thankfully, I also can't see a real-world use case in which you would want to do that, so I think it's fine to leave it as it is.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/118.