GstCollectPads-related freeze in pads mgmt

[Andrey Utkin]

2014/1/3 Sebastian Dröge <sebastian at centricular.com>:
> 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.

Could you please elaborate this?
"Flush the queue" - does it mean gst_pad_send_event (queue_sinkpad,
gst_event_new_flush_start ()) ?
And catching it means attaching another probe callback before sending the event?

> Well, the BLOCK probes can be called multiple times too.

What about BLOCK probe returning GST_PAD_PROBE_REMOVE? It doesn't
guarantee single execution, right?

> Depending on the other flags you put on them.

Do you mean that events can be also caught by probe callback, which
leads to another thread in action and race condition?

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

Need elaboration (ideally a patch to the sketch app).
Currently i see it very hard to find any elegant solution to this. The
easiest thing is to use statically allocated mutex etc. Because if we
use stack or heap allocated stuff for synchronization, these allocated
objects may get invalid at the point when the callback is fired. This
is what i meant before.


> But you're right, the IDLE probes are either called from the "main

You must have meant "BLOCKING" here.

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

So using IDLE is considered not slower than BLOCK, and guaranteed to
have no race conditions, right?

-- 
Andrey Utkin