[gst-devel] Decoupled elements and schedulers

[Benjamin Otte]

I tested opt and basic, but not fair (which is a cool scheduler and the
reason I wrote entry btw).
I think relying on decoupled elements being registered with a scheduler is
wrong.

Anyway, I'll start with the problem:
The core uses gst_scheduler_pad_link and gst_scheduler_pad_unlink to
(un)register links with a scheduler. My common sense tells me that each
link should only be registered and unregistered once. However, due to
gstbin.c:gst_bin_unset_element_sched a link may be unregistered twice,
once from gst_bin_unset_element_sched on the decoupled element and once
from gst_pad_unlink, because gst_pad_get_scheduler tells
gst_pad_unlink they both still belong to the same scheduler.
If that was confusing: it's a bit hard to explain, you can see it by
yourself by removing my patch and using entrygthread and gdb on this
pipeline:
fakesrc ! identity ! { queue ! identity ! fakesink }

Now the reason why I don't think it's correct to allow a scheduler to be
added to a decoupled element:
Imagine the following pipelines:
{ fakesrc ! identity } ! { queue ! identity ! fakesink }
{ fakesrc ! identity ! queue } ! { identity ! fakesink }
Imagine too, that two different schedulers are used for the two threads,
scheduler X for the first thread, your scheduler for the second thread.
Now the only difference between those two pipelines from a scheduler's
point of view is who controls the queue element. Since schedulers must
also work when not controlling the decoupled element, it seemed like a
valid idea to me to assume that schedulers may never control a decoupled
element.

The reason I removed adding decoupled elements to different schedulers was
now a combination of both: Since it's not ok to rely on controlling
decoupled elements anyway it shouldn't break anything and the bug above
was most easily solved by this.

Benjamin


On Mon, 29 Mar 2004, Martin Soto wrote:

> In last Changelog entry from Benjamin I see the following:
>
>         * gst/gstbin.c: (gst_bin_set_element_sched),
>         (gst_bin_unset_element_sched):
>           don't add decoupled elements to schedulers - otherwise it's
>           impossible to control if a link to a decoupled element was already
>           removed from a scheduler or not.
>
> I guess I don't really understand what the issue is here, but it does
> break my new scheduler. I need queues to be registered with one
> scheduler instance to be able to schedule their chain and get functions.
> I'm creating cothreads for them both. Having only the pad links
> registered is not enough, because in that case the cothreads will be
> created, but they will never be scheduled since they are only eligible
> for scheduling when the element goes to the PLAYING state, and I can
> only know that, if the element is registered with the scheduler.
>
> Anyway, I don't think it makes sense to have elements that are not
> registered with any schedulers. A scheduler can ignore decoupled
> elements if necessary, but the core should register them anyway.
>
> Am I missing something here?
>
> M. S.
> --
> Martin Soto <soto at informatik.uni-kl.de>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>