[gst-devel] Multi-threaded queueing locking issues

[Erik Walthinsen]

On Tue, 20 Mar 2001, Matt Howell wrote:

> i don't think the check in gstpad.c::change_state() is such a bad thing.  it's
> called in the context of the thread (the pipeline?) which was instructed to
> go to the pause state by the app, right?  it's in gstpad.c because it's pad-
> centric...  maybe i don't understand your concern here.
There is no pad_change_state()...  Only the element_change_state, which is
called within the context of the thread, but only after the thread has
woken up from within its iteration, which is the whole problem.

> it doesn't seem bad to use different ways to wake threads that are blocked
> for different reasons.  if a thread is blocked because of g_cond_wait(), it
> should be waked with g_cond_signal().  it it's blocked because of a system
> call (e.g., blocking read) use the system kill().
Only if we can unblock them all without killing the thread.  While every
element must be written so it has all of its live state within its own
object struct (so they can be shut down and restarted at the beginning
with no problems), there's still the problem of things like filehandles
which will be opened from thread context.  I just wrote a test that shows
that at least with nothing else going on, it seems that filehandles stick
around even when the thread that created them goes away.  I have no idea
if the same is true for other kinds of files.

> the spin / timeout stuff could be encapsulated in an element's change_state().
> (this requires that all elements that can block on a system call implement
> their own change_state().)  as brent points out below, this could use
> pthread_cancel() (assuming these elements are in a pthread) as a last resort
> (since it is a bit destructive ;-).
Remember though that change_state doesn't happen for an element until the
thread has been unblocked anyway, because the change_state happens from
thread context.  The thread has to be told to do the change_state...  And
pthread_cancel() has the potential problem of blowing away per-thread
state.

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_