[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 #70 from Florin Apostol <florin.apostol at oregan.net> ---
Review of attachment 313199:
 --> (https://bugzilla.gnome.org/review?bug=755169&attachment=313199)

I see a few problems with this design:
1. You introduced several recursive locks (exposing, seeking, eos, src_event,
dlloop_advance) to cope with the fact that some API functions
(gst_adaptive_demux_src_query was identified until now) can be called from
other API functions while the API or MANIFEST lock is taken. The problem with
introducing a separate lock for each scenario is that we can never be sure that
we covered all the scenarios and so the design cannot guarantee a no hang
behavior.
2. There are 2 main locks being used (API and manifest). It is not documented
(and not clear to me) what are they guarding. For example, if a variable is
shared between threads, the same lock must be acquired for all accesses. But
gst_adaptive_demux_updates_loop does not acquire any lock,
gst_adaptive_demux_update_manifest will call klass->update_manifest without any
lock, etc. Basically, every access to demux object must be guarded by the
manifest lock and this is not happening in all the places.

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