[gst-devel] A defense of non-cothreaded schedulers
in7y118 at public.uni-hamburg.de
Sat Apr 3 07:19:03 CEST 2004
On Sun, 28 Mar 2004, Andy Wingo wrote:
> Hey folks,
> I wanted to write in defense of the idea of non-cothreaded schedulers, a
> genus of which opt is a species. The argument boils down to this: a
> cothreaded scheduler will never support a pipeline with 200 elements,
> for the simple reason that you will most likely exceed the maximum
> number of cothreads (16, currently). I tried to solve this problem a
> couple of years ago with a new cothreads package that could accomodate
> unlimited numbers of cothreads, but we all know how that turned out. If
> anyone wants to go down that road again, be my guest. Barring that
> possibility, the only solution to the 200-element problem is to not use
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.
> Cothreads are not a bad thing; they're quite efficient, and our
> schedulers that use them do work, at least on some architectures (a
> problem in and of itself). But they must be used in an efficient manner,
> grouping multiple elements into a single cothread where possible. And
> where there are still too many cothreads to fit in the stack, there must
> be a way of scheduling that does not use cothreads. You see I'm
> describing opt here. I don't see another solution.
> 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?
It's not fast, but it definitely isn't slow. At least it's not the
bottleneck for 99% of applications.
> 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.
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.
Enforcing wait_async doesn't work, because wait_async only works on
loopbased elements. The same goes for any other wait condition, be it
waiting on a file descriptor in tcpsrc or a mutex in queue.
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
More information about the gstreamer-devel