[gst-devel] Scheduler requirements

[Andy Wingo]

On Mon, 2004-03-15 at 18:28, Benjamin Otte wrote:
> The problem here is the following:
> Imagine a pipeline like this: ... ! loopbased ! chainbased ! ... where the 
> scheduler decided to schedule the loopbased and the chainbased element in the 
> same cothread. Further imagine that the chainbased element pushes lots of 
> buffers from its chain function before returning. If you now happen to unlink 
> those two elements while the chainbased element is in the process of 
> outputting buffers, the cothread will end up with a stack that calls into the 
> chainbased element and returns to the loopbased element though they aren't 
> connected anymore.

We're talking about the opt scheduler, of course. In basicomega each
element does have its own cothread.

In that case you are changing the group. If you link or unlink elements
within a group, at least one of the elements will probably leave the
group. That means that the cothread is no longer valid, and it needs to
be reset to enter at the loop function's wrapper next time. (Not yet
implemented, of course.)

Unfortunately, there's no way to allow the elements to clean up when the
cothread is reset unless you allow registration of cleanup actions
(gst_element_register_cleanup_action (e, proc, data)), and make a policy
regarding data allocation in general (e.g. elements must provide for any
necessary cleanup if the pipeline changes while you call gst_pad_push or
gst_pad_pull).

Make any sense?
-- 
Andy Wingo <wingo at pobox.com>