[Webkit-unassigned] [Bug 180978] Deadlock in GStreamer video sink during shutdown

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=180978

--- Comment #9 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Miguel Gomez from comment #8)
> But I'm not sure about trying to fix the AC case as well, as in that case
> the condition is not notified from the main thread but from the compositing
> one. And notifying it from the main thread could cause gstreamer to release
> the frame while the compositor thread is still using it. In this case I
> would prefer to leave the behavior as is: the main thread is blocked while
> trying to set the pipeline to null while the compositor thread is using the
> frame. Once the compositor thread notifies the gstreamer thread, this can
> proceed to set the null state and then the main thread can continue.

Is it guaranteed however that in the AC case the compositor thread is always going to wake up the condition variable, even if both the GStreamer streaming thread and the main thread are blocked?

Also even in the AC case it seems to make sense to remember if we were cancelled (i.e. if we're shutting down), and if so just not wait (or render or anything) at all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180109/833ab2e1/attachment-0001.html>