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

[Andy Wingo]

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
cothreads.

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.

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.)

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