mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-24 17:20:36 +00:00
Code Issues 1 Projects Releases Wiki Activity

pad: Ensure that the pad is blocked for IDLE probes if they are called from the streaming thread too

Browse source 
IDLE probes that are directly called when being added will increase /
decrease the "number of IDLE probes running" counter around the call,
but when running from the streaming thread this won't happen.

This has the effect that when running from a streaming thread it is
possible to push serialized events or data out of the pad without
problems, but otherwise it would deadlock because serialized data would
wait for the IDLE probe to finish first (it is blocking after all!).

With this change it will now always consistently deadlock instead of
just every once in a while, which should make it obvious why this
happens and prevent racy deadlocks in application code.

https://bugzilla.gnome.org/show_bug.cgi?id=796895
This commit is contained in:
Sebastian Dröge 2018-07-30 18:51:35 +03:00
parent 41f1a40704
commit c3d3cf074e
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
gst/gstpad.c
View file

@ -3553,12 +3553,18 @@ probe_hook_marshal (GHook * hook, ProbeMarshall * data)
info->id = hook->hook_id;
if ((flags & GST_PAD_PROBE_TYPE_IDLE))
pad->priv->idle_running++;
GST_OBJECT_UNLOCK (pad);
ret = callback (pad, info, hook->data);
GST_OBJECT_LOCK (pad);
if ((flags & GST_PAD_PROBE_TYPE_IDLE))
pad->priv->idle_running--;
if (original_data != NULL && info->data == NULL) {
GST_DEBUG_OBJECT (pad, "data item in pad probe info was dropped");
info->type = GST_PAD_PROBE_TYPE_INVALID;