[Bug 755169] dashdemux: can we have multiple seek events at the same time?

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755169

--- Comment #37 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #36)
> (In reply to Florin Apostol from comment #34)
> > (In reply to Vincent Penquerc'h from comment #32)
> > Traditionally gstreamer accesses to an object are protected by taking that
> > object lock, so I propose to not confuse other readers and use the same
> > approach in adaptivedemux: use the demux object lock. So I propose you start
> 
> This unfortunately runs into a problem, as the object lock is taken by
> various other code, outwith adaptivedemux, leading to deadlocks when, eg,
> posting a message (the object lock is taken by
> gst_element_post_message_default).
> 
> Thus, we either need to keep using the manifest lock here, or temporarily
> unlock the object lock.
Using the manifest lock will not solve the problem.
gst_adaptive_demux_handle_message will need to get the manifest lock to access
the demux->streams (currently it doesn't and that's a bug), so you run into the
same deadlock.
The solution is to temporarily unlock the object lock, but for each of those
cases we need to see what are the possible consequences. 

> 
> This also explains why there's a temp unlock where you said:
> > Personally I don't see why we should unlock. So what if it post messages on the bus?
> 
> It would not be necessary to unlock if we were using the manifest lock (as I
> don't think any recursive calls into adaptivedemux by way of messages are
> expected).
It will be necessary because you need to protect
gst_adaptive_demux_handle_message. Try to grab the manifest lock there and I
think it will deadlock.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.