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

[Tim 'Tool-Man' Taylor]

Matt Howell wrote:

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

Now, you're probably going to think I'm trying to pick a fight :)  ...

Unless I've misunderstood one of the scenarios (a distinct possibility) 
a more accurate heading would be: "Liveness Problems and Proposed 
Solutions".

I don't see how they are race conditions, either.  It's tempting to 
think of deadlock as a type of race condition, but typically the term 
"race condition" is reserved for describing code that relies on 
scheduling to keep other threads from accessing objects in intermediate 
(i.e. inconsistent) states.

I don't mean to be pedantic.  However, my C-fu is minimal and my 
concurrent C programming skills are non-existent, so I can't divine 
understanding by perusing the code...at least not easily.  The higher 
level documentation and notes are how I grok gstreamer right now.

I'm /not/ saying these scenarios don't have deadlock or race conditions. 
  I'm saying "I don't see them".  That may mean they aren't there.  More 
likely it means means I lack the understanding of gstreamer internals to 
"see" them based on your notes.  This is probably fine.  Your notes were 
intended for internal developers, not for gstreamer groupies like me :)


-- 
Tim Taylor
tim at tool-man.org