[gst-devel] 0.9 proposals

[David Schleef]

On Wed, Dec 15, 2004 at 01:28:46PM +0100, Wim Taymans wrote:
> > Yes.  It's quite clear that at the bare minimum, we need to allow
> > elements to start up threads and execute code.  There should be
> > a GstElement subclass or a helper library for this.
> 
> Is this element allowed to make gst core method calls? 

The element itself is allowed to call anything in the 'plugin API'
(i.e., the set of functions that are used by elements).  The
subthread is allowed to call only re-entrant functions in that API.
Depending on whether or not the schedulers use subthreads (as I
mentioned in the previous email), some or all of the plugin API
would be re-entrant.

> Can it fire signals at will or does it have to call special methods that
> marshal the signals to the main thread?  

(I assume you mean from the subthread.)  It would have to be the
latter, since calling g_signal_emit() doesn't support this.

> Thanks for clarifications, I see what you mean now. This is indeed very
> well doable. I'm still struggling with the drawbacks though:
> 
> - data passing is quite heavy as each push/pull/event/signal/poll needs
> to go through a scheduler. People are asking that Gstreamer should add
> less overhead (current is at about 3%, in a last benchmark encoding a
> theora video), I know there are many causes for this but scheduling is
> currently using up quite some CPU and even that is currently supposed to
> be quite fast with opt...

This appears to be a false optimization.  If it's slow to go through
the scheduler, we should make that path faster, since that path is
used a lot, and not every element can chain-call the next.  There
are a number of problems with chain-calling other elements, including
having to lock multiple elements at the same time, having to check
that the called element is ready to be scheduled, etc.  It's currently
a mess, and rather than perpetuate that mess, I'd prefer to rip it out
and figure out later whether chain-calling should be readded, and if
so, do it right.

> - latency of events can get high as the event can only be scheduled when
> the current event has been handled (you mention the videosink).

Huh?

> - (re)writing the elements as state machines.

Elements in general do not need to be rewritten.  Most can be
converted to subclasses of GstGetElement, GstChainElement, and
GstLoopElement, which will provide roughly the old behavior.  In
some cases, this will not work or will be suboptimal, so we can
fix those case-by-case.  Yes, eventually, all elements should be
refactored somewhat to use their optimal parent class.  These
classes will have the ability (if a flag is set) to start up a
subthread for the legacy code, so we don't even have to modify
blocking elements until we feel like it.

> - marshalling of signals/methods over thread boundaries. You basically
> need to check in each method call if the target object(s) run in the
> same current thread and marshall if not.

This needs to be done anyway, unless every element is run from the
main thread.

> Have you considered using cothreads for this kind of scheduling as a way
> of implementing more efficient scheduling and plugin development?

Didn't I have this discussion a few days ago?  I think that
cothreads have zero interesting features, and plenty of drawbacks.
My overarching goal for 0.9 is to _get elements off the stack_,
that is, ensure that an element's get/chain/loop/iterate function
is part of the stack trace as little time as possible.  This ultimately
gives us more freedom to manipulate elements while they're running --
since if there are fewer elements locked up at any given time, there
are fewer to wait for.



dave...