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

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.
This commit is contained in:
Wim Taymans 2002-06-23 12:50:12 +00:00
parent 839c62927c
commit bcb921d550

View file

@ -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;
}