[gst-devel] Decoupled elements and schedulers

[Benjamin Otte]

On Sun, 4 Apr 2004, Andy Wingo wrote:

> If you accept my cothreadless scheduler defense (do you?),
> gst_element_yield really shouldn't be allowed. Well, you could arrange
> for it to longjmp back to some earlier point in the call stack... I
> really think, though, that we shouldn't rely on state stored in the
> stack between pushes and pulls. Loop functions should just return.
> ("Process functions" would be a better name.)
>
I don't think we need _yield anymore, but there is (or better: was) a
reason to allow it, that basically goes for libraries that work like this
(vorbisfile is an example):

stupid_lib_setup (&stupid_lib_callbacks);
stupid_lib_process ();

... and then perform the yield in one of the callbacks. Here you couldn't
return from the loop function.

Note the careful wording of "the scheduler is free to suspend" btw, which
explicitly allows you to just don't care about yields :)

We'll change the scheduling behaviour significantly in the 0.9 timeframe
anyway, so the element that wraps the stupid libs will have to do the
cothreading itself, which makes a lot more sense.

Benjamin