[gst-devel] A defense of non-cothreaded schedulers

[Andy Wingo]

On Sat, 2004-04-03 at 17:18, Benjamin Otte wrote:
> I consider a cothread implementation buggy that does not support unlimited
> amounts of cothreads. That's why I don't even consider omega cothreads
> when writing my new scheduler.

A convenient assumption :-)

> > I am discounting the gthread implementation of cothreads, for efficiency
> > reasons. It's a nice hack, but not... well, not opt-imal.
> >
> Have you profiled it?

Nope. But I know it's not realtime-safe. I want to run gst with low
latency, and threads are not deterministic.

> > So, unless people have worthwhile arguments that cothreads are the only
> > way to go, I'd like for us to stop complaining about opt as an idea.
> > Complaining about bugs, fine. But opt is a necessary scheduler for
> > GStreamer to have. (And it works damn well for me, and I stress it quite
> > a bit.)
> >
> It doesn't work damn well for me for a variety of reasons for which
> keeping huge lists of buffers inside the scheduler is the biggest one.
> This is just ugly and breaks demuxing.

Incidentally, since my graph-reordering patch you shouldn't see huge
numbers of buffers in bufpens any more, but I'm not familiar with
demuxers. (How many buffers of type A are output for one of type B?)

> Another thing that you'll never get solved correctly is running a simple
> video player in one scheduler. If the videosink calls wait, you can't
> switch to another part of the pipeline, because you can't switch back.

I don't understand this point. One, why would you want a single-threaded
video player? And two, opt support recursively entering the scheduler.
What's the big difference? (Sounds like it's probably with the demuxers,
which I'm again not so familiar with.)

> The correct solution for all this is to allow a better model for how
> elements are scheduled, which we'll definitely work on for 0.9, or maybe
> even 0.8.

/me becomes curious ;)

Peace,
-- 
Andy Wingo <wingo at pobox.com>