GstCollectPads-related freeze in pads mgmt

[Sebastian Dröge]

On Fr, 2014-01-03 at 14:22 +0200, Andrey Utkin wrote:
> 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?

Sure, but a testcase would make it more likely that someone looks into
this :)

> >> 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?

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).

> > 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?

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140103/2c194358/attachment.pgp>