GstCollectPads-related freeze in pads mgmt

[Andrey Utkin]

2014/1/3 Sebastian Dröge <sebastian at centricular.com>:
> I didn't read the code yet. What is your algorithm, what are you doing?
> As I understand it you want to provide a convenience tee that
> automatically puts a queue after each tee srcpad.
>
> So what you would do there when releasing a pad is that you block the
> corresponding tee srcpad, from that block callback set the queue to NULL
> state and release all pads and remove the queue from the bin.
> This would however wait until the queue runs empty (which you can
> improve if necessary).

The explanation of algorithm is given in another post here, "[example]
A bin with tee and queues on srcpads". You resembled it correctly.
Regarding queue emptying, how exactly is it supposed to be done in
this situation?

>> > 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?
>
> It's not required to use here, but it has some advantages in some cases.
> It's just a different type of block :)
>
> Why did you require a static mutex in that case but not for the pad
> blocks?

Seems above i have confused BLOCKING (IDLE | BLOCK) with IDLE.
If i am right, then with BLOCK callback, the callback is executed from
exactly one thread - the pushing one on this pad (however it is
interesting to consider a change of pushing thread somewhere deep
inside), so locking and state checking inside callback is not
required.
With BLOCKING (IDLE | BLOCK) the callback can be executed on pushing
thread or main thread (the one calling gst_pad_add_block()). There
things go nasty and you can get a second execution of callback even if
you would like to have it executed once. I have expressed my opinion
for having static mutex in comment here:
https://bugzilla.gnome.org/show_bug.cgi?id=721096#c8

But now i see you advised IDLE probe. What's its meaning? The manual
only says "probe idle pads and block". By analogy, i guess such a
callback is executed directly on the calling thread, while the thread
pushing through the pad is blocked. Is it so?
If so, can IDLE probe callback be used for unlinking (i.e. instead of
BLOCK probes in the given code)?

-- 
Andrey Utkin