[gstreamer-bugs] [Bug 626784] element: link_many might assert elements are in paused or playing

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=626784
  GStreamer | gstreamer (core) | git

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #7 from Wim Taymans <wim.taymans at gmail.com> 2010-08-19 11:26:35 UTC ---
The only purpose of the STATE_LOCK is to make sure that no threads can execute
_set_state() at the same time. The most important use is so that the async
state changes in gstbin execute only when the _set_state() is done.

As a side effect, it can also be used to make sure that no state changes can be
performed by the application (surround some code with the STATE_LOCK). The lock
is recursive too and is supposed to be taken before any other lock.

Without the STATE_LOCK, it is possible that a set_state() is executed right
between getting the element state (old state) and adding the pad, leaving the
pad in the wrong state. 

Another possible solution is to check if the state cookie changed between
getting the state and after adding the pad. If it did, we need to redo the pad
activation (although core might have complained already about adding inactive
pads to running elements). 

So it looks like this patch (with the STATE_LOCK) would not cause any problems
that I can think of. I would leave the lock.

On a side note, I'm not entirely sure that we don't have other situations where
we should but didn't take the STATE_LOCK..

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.