[gst-devel] INCSCHED1: scheduling / threading branch of GStreamer

[Matt Howell]

you're correct, tim -- i used the term loosely.  a more precise title would be
"State-change Race Conditions and Proposed Solutions"

Tim 'Tool-Man' Taylor wrote:

> Matt Howell wrote:
>
> [snip]
>
> > ---------------------------------------------------
> > -  II. Deadlock Scenarios and Proposed Solutions  -
> > -      (in the order they will be implemented)    -
> > ---------------------------------------------------
> >
> > 1. A downstream element "waits" for a buffer from its upstream element,
> >    a state change happens and "pauses" the upstream element -- the
> >    downstream element is blocked and cannot execute its change_state.
> >
> [snip]
>
> > 2. Element "blocked" on getting I/O and cannot execute its change_state.
> [snip]
>
> > 3. Element using a library (code out of its control) which blocks for
> >    some reason (e.g., using real blocking I/O) so main loop never gets
> >    run to execute change_state.
>
> Unless I'm missing something, none of these scenarios describe Deadlock.
>   They describe liveness problems.  Deadlock is when two threads lock on
> eachother, each awaiting a condition that only the other thread can fulfill.
>
> --
> Tim Taylor
> tim at tool-man.org
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel