This makes more sense and solves the locking problem when a loop based element is...

Original commit message from CVS:
This makes more sense and solves the locking problem when a loop based
element is selected as the entry point.

diff --git a/gst/schedulers/gstbasicscheduler.c b/gst/schedulers/gstbasicscheduler.c
index 02c713d..b1782c9 100644 (file)
--- a/gst/schedulers/gstbasicscheduler.c
+++ b/gst/schedulers/gstbasicscheduler.c
@@ -272,6 +272,7 @@ gst_basic_scheduler_loopfunc_wrapper (int argc, char *argv[])
 
   GST_DEBUG_ENTER ("(%d,'%s')", argc, name);
 
+  gst_object_ref (GST_OBJECT (element));
   do {
     GST_DEBUG (GST_CAT_DATAFLOW, "calling loopfunc %s for element %s",
               GST_DEBUG_FUNCPTR_NAME (element->loopfunc), name);
@@ -281,7 +282,17 @@ gst_basic_scheduler_loopfunc_wrapper (int argc, char *argv[])
   } while (!GST_ELEMENT_IS_COTHREAD_STOPPING (element));
   GST_FLAG_UNSET (element, GST_ELEMENT_COTHREAD_STOPPING);
 
+  /* due to oddities in the cothreads code, when this function returns it will
+   * switch to the main cothread. thus, we need to unlock the current element. */
+  if (SCHED (element)) {
+    if (SCHED (element)->current && SCHED (element)->current->post_run_func) {
+      SCHED (element)->current->post_run_func (SCHED (element)->current);
+    }
+    SCHED (element)->current = NULL;
+  }
+
   GST_DEBUG_LEAVE ("(%d,'%s')", argc, name);
+  gst_object_unref (GST_OBJECT (element));
   return 0;
 }