[gst-devel] Loop-based elements and pause state

[Benjamin Otte]

On Thu, 19 Aug 2004, Ramón García wrote:

>  --- David Schleef <ds at schleef.org> escribió:
> > Loop-based elements are not "infinite loops", they
> > are supposed to
> > do as little as possible and then return.
> > Infinite-loop elements
> > will fail miserably.
>
> Are you sure?
>
> A loop-based element should implement the
> release_locks function. Before a state change, that
> callback will be called. That function should arrange
> things so that it causes the termination of the loop.
> For instance, the element might contain a variable
> that if set the loop terminates, or the element
> contains a pipe, so that the loop terminates when
> there is data available in the pipe, and the
> release_locks function writes data to the pipe.
>
> The release_locks callback is specified in
> GstElementClass.
>
> The release_locks function runs in the thread that
> caused the state change, such as the application
> thread. For the mechanism above to work, that thread
> must be different from the thread of the loop function
> (the thread of the element). Placing the element in
> its own thread would be enough.
>
release_locks is morew or less a hack to get elements blocking in a read
function or waiting on a cond back into business. It's not supposed to
make loopbased elements stop. If loop elements can stop, they should just
do it instead of infinitely looping.

Infinite looping is supposed to be supported in the current release (that
support will require an extra thread in 0.10), but the opt scheduler
doesn't handle it nicely, so you'd most likely require a different
scheduler.

Benjamin