GstCollectPads-related freeze in pads mgmt

[Sebastian Dröge]

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

Yes

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

Yes it doesn't. The second call could already be right in front of the
"return GST_PAD_PROBE_REMOVE" in your callback.

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

There can be multiple conditions that lead to the block being called.
And the pad being blocked for one condition does not mean that the other
conditions can't happen anymore. Just think of serialized events and
data flow vs. out of band or upstream events.

Also the case I mentioned above.

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

The gst_pad_add_probe() takes a GDestroyNotify for the data :) Implement
refcounting for the data for example.

You could have an integer X initialized to FALSE and then do this at the
top of your callback:

  if (!g_atomic_int_compare_and_exchange (&X, FALSE, TRUE))
    return GST_PAD_PROBE_OK;

(or REMOVE or whatever)

> > But you're right, the IDLE probes are either called from the "main
> 
> You must have meant "BLOCKING" here.

No, only IDLE probes can be called from the thread that calls
gst_pad_add_probe(). All others are called from the thread that triggers
the probe, which is the streaming thread for anything serialized.

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

Which race conditions? :) The ones you mention above with the probe
being called multiple times (or even after returning REMOVE) are no real
race conditions. That's part of the API and your callbacks have to
consider that. And it's true for every type of probe.

But IDLE is even faster in theory because you don't have to wait for
actual data flow. The probe callback can be called immediately.

-- 
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/20dbe80c/attachment-0001.pgp>