GstCollectPads-related freeze in pads mgmt

[Andrey Utkin]

2014/1/3 Sebastian Dröge <sebastian at centricular.com>:
> On Fr, 2014-01-03 at 11:33 +0100, Sebastian Dröge wrote:

>> Can you open a bug about this with a minimal testcase?

Is the original posting OK to be in bug description?

>> Blocking (downstream block at least) the srcpads in front of the muxer
>> and the removing them should work just fine and not deadlock. There must
>> be no streaming thread inside collectpads in the muxer at that time, and
>> also not in the future until you unblock. There might be more calls to
>> the block callback though and you must block there too.
>
> Note that you need to block the most upstream pad that you want to
> remove. So if you want to remove the tee srcpad, the queue and the bin
> srcpad (the ghostpad), you need to block the tee srcpad. Blocking at the
> bin srcpad should still make sure that the pad's streaming thread is not
> inside the muxer.

This paragraph is hard for me to comprehend. If we consider the given code,
- is there a mistake in algorighm?
- what can/should be fixed in code?
- is it possible to implement the given object relations scheme at all?

> Also depending on what you want to do, you can also use an idle probe.

I have found idle probe unpredictable, and requiring static mutex. In
my opinion it is very uncomfortable to use. Is it still necessary to
use exactly it?

-- 
Andrey Utkin