[PATCH][RFC] tee: hold private mutex in handle_data

[Andrey Utkin]

After looking at above (see "tee: needs fixing locking in gsttee.c?"), i've
made such a patch and now i am running with it.
It allows me to release requestpad safely from main thread.
But if i release it from BLOCK probe callback, the callback is called from
within handle_data() and hangs on secondary GST_TEE_DYN_LOCK, obviously because
it is not recursive. Could we afford recursive mutex?

Before this patch, GST_TEE_DYN_LOCK was used only in release_pad(), which does
not make sense.
---8<---

---
 plugins/elements/gsttee.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/plugins/elements/gsttee.c b/plugins/elements/gsttee.c
index a6d4b9d..03eaaa2 100644
--- a/plugins/elements/gsttee.c
+++ b/plugins/elements/gsttee.c
@@ -580,6 +580,7 @@ gst_tee_handle_data (GstTee * tee, gpointer data, gboolean is_list)
   if (G_UNLIKELY (!tee->silent))
     gst_tee_do_message (tee, tee->sinkpad, data, is_list);
 
+  GST_TEE_DYN_LOCK (tee);
   GST_OBJECT_LOCK (tee);
   pads = GST_ELEMENT_CAST (tee)->srcpads;
 
@@ -600,6 +601,7 @@ gst_tee_handle_data (GstTee * tee, gpointer data, gboolean is_list)
     } else {
       ret = gst_pad_push (pad, GST_BUFFER_CAST (data));
     }
+    GST_TEE_DYN_UNLOCK (tee);
     return ret;
   }
 
@@ -664,6 +666,7 @@ restart:
     pads = g_list_next (pads);
   }
   GST_OBJECT_UNLOCK (tee);
+  GST_TEE_DYN_UNLOCK (tee);
 
   gst_mini_object_unref (GST_MINI_OBJECT_CAST (data));
 
@@ -681,6 +684,7 @@ error:
   {
     GST_DEBUG_OBJECT (tee, "received error %s", gst_flow_get_name (ret));
     GST_OBJECT_UNLOCK (tee);
+    GST_TEE_DYN_UNLOCK (tee);
     gst_mini_object_unref (GST_MINI_OBJECT_CAST (data));
     return ret;
   }
-- 
1.8.1.5