GstCollectPads-related freeze in pads mgmt

[Sebastian Dröge]

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

You could flush the queue from the probe on the tee srcpad, and catch
and drop the flush on the srcpad of the queue. And then set the queue
state to NULL.

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

Well, the BLOCK probes can be called multiple times too. Depending on
the other flags you put on them. Instead of a mutex you could also just
use a single integer and atomic operations, g_atomic_int_exchange() for
example, to make sure your callback is only called once (and for the
second times just returns immediately).


But you're right, the IDLE probes are either called from the "main
thread" or the streaming thread, while the BLOCK probes are always only
called from the streaming thread. However it can happen that the BLOCK
probe is *never* called if no data is coming anymore after you added the
probe. Or just very very late if next data comes later. The IDLE probes
don't have this problem. You can use the IDLE probes for unlinking here,
I actually have an example for something like this with tee around here
that uses IDLE probes only.

-- 
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/0b12f387/attachment.pgp>