[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 #58 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #57)
> Why not just have the api lock recursive as I had earlier ? That's already
> two exceptions, and the first one adding yet another lock. While it might
> mean we allow some other nested event/query instead of deadlocking, it
> doesn't seem like a large problem, and we avoid the extra complexity.

The api_lock is intended to make sure that the operation (eg seek) is
serialised. The operations protected by this lock should be the ones that do
multiple changes on demux object (eg reconfigure, stopping tasks, changing all
the streams, etc) and you want to make sure other threads do not interrupt
until all the steps are done. Basically, it guarantees the invariant at the
begging and at the end of the operation.
But if the lock is recursive, it will fail to detect situations when you end up
calling seek from another seek. If this happen, a thread might start a sequence
of changes while it was already in a sequence of changes. Because demux uses
virtual functions, it is hard to prove this cannot happen. This is why I want
to avoid recursive mutexes and use them only to detect if that thread is
already performing a sequence of operations or not. The recursive mutex is used
to determine if the api_lock is already hold or not.

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