[Bug 697215] pad: discoverer timeout could flush the element pads while peer seetcaps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=697215
  GStreamer | gstreamer (core) | 1.x

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #240540|none                        |rejected
             status|                            |

--- Comment #2 from Sebastian Dröge (slomo) <slomo at circular-chaos.org> 2013-07-24 09:37:41 UTC ---
(From update of attachment 240540)
<slomo> wtay: https://bugzilla.gnome.org/show_bug.cgi?id=697215  any idea about
this one? it shouldn't happen anymore because of changes elsewhere, but why can
it happen that the stream-lock is not taken there already (see the patch)?
<wtay> slomo, we don't take stream-lock on srcpads only on sinkpads
<wtay> slomo, and srcpads in pull mode
<slomo> i see
<wtay> also also on srcpads when using a task
<wtay> well, it does not have to be
<slomo> why not?
<wtay> there is no need to serialize pushes on the srcpad
<wtay> only on the sinkpads
<slomo> because when not using a task, it should already be protected by the
sinkpad stream-lock?
<wtay> well, there is no need to serialize
<wtay> and yes, for shutdown of the element, we use the sinkpad lock
<wtay> when that's taken, we are sure nothing is inside the element pushing on
the srcpad either
<slomo> ok, so that patch is not useful and only hiding another bug (that is
fixed now)?
<slomo> do we also take the srcpad lock for shutdown? e.g. when the srcpad has
its own task running?
<wtay> we do take the lock in shutdown but when in push mode, core does not
take it
<wtay> so if the element is using a task, core will wait for the task to
complete

-- 
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.