GNOME Bugzilla – Bug 756645
multiqueue: Improve incoming SEGMENT handling
Last modified: 2015-10-19 12:42:07 UTC
See comment
Created attachment 313378 [details] [review] multiqueue: Improve incoming SEGMENT handling Previously this code was just blindly setting the cached flow return of downstream to GST_FLOW_OK when we get a SEGMENT. The problem is that this can not be done blindly. If downstream was not linked, the corresponding sinqlequeue source pad thread might be waiting for the next ID to be woken up upon. By blindly setting the cached return value to GST_FLOW_OK, and if that stream was the only one that was NOT_LINKED, then the next time we check (from any other thread) to see if we need to wake up a source pad thread ... we won't even try, because none of the cached flow return are equal to GST_FLOW_NOT_LINKED. This would result in that thread never being woken up
Review of attachment 313378 [details] [review]: The logic sounds reasonable. If the tests still pass, I say push it :)
Pushed to both master and 1.6 commit ebeee60c3f6e4cdaf54e3d5f5569cadc5019f0f3 Author: Edward Hervey <edward@centricular.com> Date: Thu Oct 15 16:32:42 2015 +0200 multiqueue: Improve incoming SEGMENT handling Previously this code was just blindly setting the cached flow return of downstream to GST_FLOW_OK when we get a SEGMENT. The problem is that this can not be done blindly. If downstream was not linked, the corresponding sinqlequeue source pad thread might be waiting for the next ID to be woken up upon. By blindly setting the cached return value to GST_FLOW_OK, and if that stream was the only one that was NOT_LINKED, then the next time we check (from any other thread) to see if we need to wake up a source pad thread ... we won't even try, because none of the cached flow return are equal to GST_FLOW_NOT_LINKED. This would result in that thread never being woken up https://bugzilla.gnome.org/show_bug.cgi?id=756645