[gst-devel] 0.9 proposals

[David Schleef]

On Thu, Dec 02, 2004 at 11:23:37PM +0100, Martin Soto wrote:
> Yeah, it lies in some middle point between "threads only" and "no
> threads at all".

Er, you're saying "threads, cothreads, and pluggable schdulers",
Wim is saying "threads, no cothreads, and (?)", and Benjamin is
saying "no threads, no cothreads, and no pluggable schedulers".
AFAICT.  (Anyway, I'm not interested in defending this point,
it was just an observation.)

> So, you want to reduce the complexity of the core at the cost of
> increasing the complexity of almost every element. There is one core,
> but there are a lot of elements. I would rather put the complexity in
> the core and try to hide (encapsulate, abstract) it as best as I could.
> But that's probably only me.

This has been argued in the past, and there's adequate evidence that
the complex-core/simple-elements model is failing.  If you make the
assumption that there is no code sharing between elements, then
simplifying the core generally means making elements more complicated.
However, this assumption is false -- part of the plan of simplifying
the core is to create base classes that mimic much of the existing
core functionality, especially loop/chain/get-based elements, thereby
sharing much of the extra code that would otherwise be required by
elements.

I want a simple core and simple elements and a collection of helper
libraries and base classes that bridge the two.

> Anyway, what I'm proposing is to extend and improve the scheduler API in
> such a way that these models can be implemented in a clean, properly
> encapsulated way. If I later decide to implement an scheduler that
> combines five different threading models for the amazement and
> bewilderment of the general population, that's my problem, but as long
> as the scheduling interface is well specified, no one else has to worry.

There's also adequate evidence that having multiple pluggable
schedulers is a bad idea.

> >  - NPTL is (allegedly) faster than Pth.
> 
> Really? Let's give it a try.

On my system, about 80% of the time used by the gthread-switch
program is used by glib initialization.  Can you confirm this?

> In the
> gthreads case there's a big difference. Does anyone have a good
> explanation for that?

Yes.  Profiling by using 'time' is a shot in the dark, at best.



dave...