[gst-devel] Request for ideas: decoupled elements

[Andy Wingo]

On Wed, 24 Sep 2003, in7y118 at public.uni-hamburg.de wrote:

> (This is mainly a mail to the core devs, as I'm a bit out of ideas - so you 
> others, please don't get all suicidal if you don't understand everything)

I'm not really qualified to talk about threading. But I'll do a little
bit anyway ;)

> The problem is that GStreamer doesn't handle the "one element belongs
> to multiple schedulers" fact and that causes some issues.

It seems to me we need to work backwards from these issues to find the
proper solution. It's one way to do it, anyway. Let's look at the ones
you brought up.

> Imagine this simple pipeline:
> { filesrc } ! { queue ! filesink }   (example 1)
> This should be the same in functionality as:
> { filesrc ! queue } ! { filesink }   (example 2)
> or even:
> { filesrc } ! queue ! { filesink }   (example 3)
> though I wouldn't try that last one...

Hmm. It seems these should be the same in topology as well. Since there
is no difference between 1 and 2, shouldn't the queue be added to both
managing bins? Note the "should", that's clearly not how things are now.
Is it too ambiguous for a queue to have two parents? Don't know if that
solves anything, but it makes the pipeline topology clearer in my mind.

Of course, that logic would dictate that the queue in example 3 have
three parents. Gah! A cleaner solution, topologically, would have
DECOUPLED elements exist without parents (i.e., they would not be
children of any bin). The GstElement::sched and :: sched_private fields
could then be NULL, and schedulers and data for each side could be
stored in some subclass of GstElement as you were proposing. This might
require pads to have pointers to their schedulers, although they already
have sched_private data.

> - Signal emissions can be started from totally unexpected threads. The EOS 
> signal in a queue always gets emitted from the scheduler that controls the 
> srcpad. (This would mean that the EOS signal of the filesrc thread in example 2 
> gets emitted in the context of the filesink thread, how's that for assumptions 
> about signal handlers?)

Should a queue emit EOS? Dunno, but this seems to be just a case of
having where the signals are emitted following a well-defined rule (as
they do now). Confusing, but predictable so.

> - State changes lead to interesting races. If you set the whole pipeline to 
> PLAYING in example 1, the filesrc thread may already be pushing data to the 
> queue while the queue has not yet changed state. (This btw is the cause for 
> the "pushing data into inactive pads is not allowed" g_warning's you get 
> sometimes).

Hm, this should probably be special-cased in queue (i.e., when both pads
are connected set yourself to PLAYING or so). Hackish, but support for
threads and queues requires a lot of special-casing in general.

> - What scheduler sets the clock on decoupled elements?

What do queues need clocks for? Good question though.

In the end, any refactoring we do should be driven by the desire to
produce a design that will prevent *specific bugs* as we know them now.
Solutions should be judged according to how well they deal with those
bugs. The list as you have it now is

1. Unblocking elements (why is this a problem again? /me ignorant)
2. Funny sources for signal emission
3. Races in state changes
4. Setting clock on decoupled elements

Of these, I would consider (3) to be the only bug we need to fix soon
(before 0.8). The others are not desirable behavior, but they're not
problems as such.

Again, I'm ignorant, and I don't know what the proper solution is. But
how do you see my description of the problem? And let me know what you
think about parentage as the way to investigate the solution to this.
Wim if you're around a word or two would also be appreciated ;)

Regards,

wingo.