[gst-devel] Opt fix?

[iain <ia...@pr...>]

So, um, yeah...
Here's the patch for opt that got my pipeline working. Pipeline is

filesrc --> mad --> one-to-n --> int2float --> Marlin-sample-sink
                             --> int2float -->

The problem it was having was that the sample sink (being loop based)
was emptying the bufpen, and then when it did its next gst_pad_pull on
it's sink pad, the scheduler was putting the i2f group on the
scheduler's runqueue and scheduling it. However, when the runqueue also
had the marlin-sample-sink's group on the queue ahead of the i2f group,
so it was trying to run it instead. So that lead the the
Marlin-sample-sink being locked twice, and a deadlock.

My solution is not to add a group to the runqueue if that group is
already at the head of the queue[1], and then when we need to schedule a
different group, disable the first group so that the second group will
get run.

It works for me[2], but I have no idea whatsoever about what is going
on, and I'm sure that there's nasty semantic things that I've completely
ignored, so please please please please please test this patch against
everything you can possibly find. (It's patched from HEAD)

Company, you said in the bug I filed that you had seen similar issues
with other loop based elements like alsasink. Can you see if this fixes
them too?

The other thing in the patch is that it removes all the g_list_lengths
that the debugging code is calling, as that can slow stuff down if the
list is being walked every iteration.

Now to find out why it doesn't work if I substitute spider for mad in
the pipeline, anyone else want to have a go at that?

iain
[1]One issue: Should the whole queue be checked?
[2]Marlin loads samples again :D
-- 
"Miss Celine Dion sings lovesongs while our cities burn"