[Bug 747852] pad: idle probe doesn't block pad from pushing data

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=747852

--- Comment #7 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #6)
> Review of attachment 301572 [details] [review]:
> 
> ::: gst/gstpad.c
> @@ +1395,3 @@
>        /* Keep another ref, the callback could destroy the pad */
>        gst_object_ref (pad);
> +      pad->priv->idle_running++;
> 
> Can this ever be bigger than 1?

Theoretically you can gst_pad_add_probe from some thread while another thread
is running your idle probe from another call to gst_pad_add_probe. Not sure
there is a use case for this happening in the same pad but it would be annoying
to debug so better protect from the beginning.

> 
> @@ +3449,3 @@
>        (info->type & GST_PAD_PROBE_TYPE_BLOCK) == GST_PAD_PROBE_TYPE_BLOCK;
>  
> +  do_pad_idle_probe_wait (pad);
> 
> Maybe you want to do something with the return value here, but otherwise
> this makes sense :)

Good point, should check for FLUSHING

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.