[Bug 768154] d3dvideosink: start/stop concurrency between multiple sinks

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Jonathan Roy <jroy at adetelgroup.com> ---
We need something to protect access to klass->d3d.thread, which klass->lock
obviously cannot fulfil, because the thread in question (the window proc
thread) itself locks klass->lock through d3d_class_ calls. That is why the lock
has to be released momentarily when _start or _stop instantiate or terminate
the thread (and intently waiting for that to happen).

As far as I can tell, the window proc thread never calls _start or _stop. Those
methods are called on element state changes triggered outside of the element.
Therefore, nothing will block on klass->start_stop_lock other than the _start
and _stop calls, thereby achieving the serialization effect we are looking for.

We stumbled on this issue through robustness testing (start/stop cycles every
few seconds running for several hours). Doesn't occur that often, and it is
quite possible it would never happen while running only a single sink at a
time.

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