[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 #17 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #13)
> Sure, but we're getting into another problem here. I don't think it's good
> to wait to have fixed everything that can be connected to this. We'll end up
> with one gigantic patch in a few months' time. So while you're right, that
> demux->streams use was broken (in the locking sense) in the first place, so
> I wouldn't care about that here, and then go on to fix the demux->streams
> locking separately. Because it's likely fixing demux->streams will also link
> to other missing locking elsewhere, etc. Unless you know it's not if you
> already looked at demux->streams locking ?

I propose that in this ticket we fix the concurrent seek problem. For this,
adding a new lock and holding it for the whole duration of handling seek event
should be enough.

I've raised several bugs related to locks in adaptive demux. In my opinion:
1. we need to review and reduce the usage of demux->cancelled flag, because it
is broken. See https://bugzilla.gnome.org/show_bug.cgi?id=755230
2. Add a new lock for API level serialization. We initially use it for seek
events, and then reuse it for any event handling (manifest lock was supposed to
be used for this, but because it is used in the download_loop we cannot use it)
3. Document all the existing locks and their purpose. Document what data is
shared and between which threads. Currently we have 3 categories: 
a) _src_chain handling streaming; 
b) download_loop handling stream configuration; 
c) external calls handling events. 
Each of those have differnet needs and I don't have a clear picture about where
those needs intersect. 
4. Review the code to make sure that each shared variable is properly locked
before being used

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