Skip to content
  • enne@google.com's avatar
    6faa8eab
    [chromium] Fix deadlock between WebMediaPlayerClientImpl dtor and PutCurrentFrame · 6faa8eab
    enne@google.com authored
    https://bugs.webkit.org/show_bug.cgi?id=96010
    
    Reviewed by James Robinson.
    
    Source/Platform:
    
    Add some additional clarifying comments.
    
    * chromium/public/WebVideoFrameProvider.h:
    (Client):
    (WebVideoFrameProvider):
    
    Source/WebKit/chromium:
    
    The key fix here is that the destructor no longer has a mutex.
    The m_compositingMutex was supposedly protecting races between
    ~WebMediaPlayerClientImpl and setVideoFrameProviderClient. The
    former is only called from the main thread and the latter is called
    from the compositor thread only when the main thread is blocked (and
    it already asserts that this is the case).
    
    In addition, the m_providerMutex in CCVideoLayerImpl prevents the
    destruction of WebMediaPlayerClientImpl, thus keeping the frame
    acquired via getCurrentFrame alive until putCurrentFrame is called.
    These functions are only called by the client, and comments are added
    to the interface to better document this.
    
    To prevent a race between load() and getCurrentFrame/putCurrentFrame
    (which are called from different threads) a new m_webMediaPlayerMutex
    to replace part of what the old m_compositingMutex was doing.
    
    * src/WebMediaPlayerClientImpl.cpp:
    (WebKit::WebMediaPlayerClientImpl::~WebMediaPlayerClientImpl):
    (WebKit::WebMediaPlayerClientImpl::load):
    (WebKit::WebMediaPlayerClientImpl::loadInternal):
    (WebKit::WebMediaPlayerClientImpl::setVideoFrameProviderClient):
    (WebKit::WebMediaPlayerClientImpl::getCurrentFrame):
    (WebKit::WebMediaPlayerClientImpl::putCurrentFrame):
    * src/WebMediaPlayerClientImpl.h:
    (WebMediaPlayerClientImpl):
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128082 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    6faa8eab
    [chromium] Fix deadlock between WebMediaPlayerClientImpl dtor and PutCurrentFrame
    enne@google.com authored
    https://bugs.webkit.org/show_bug.cgi?id=96010
    
    Reviewed by James Robinson.
    
    Source/Platform:
    
    Add some additional clarifying comments.
    
    * chromium/public/WebVideoFrameProvider.h:
    (Client):
    (WebVideoFrameProvider):
    
    Source/WebKit/chromium:
    
    The key fix here is that the destructor no longer has a mutex.
    The m_compositingMutex was supposedly protecting races between
    ~WebMediaPlayerClientImpl and setVideoFrameProviderClient. The
    former is only called from the main thread and the latter is called
    from the compositor thread only when the main thread is blocked (and
    it already asserts that this is the case).
    
    In addition, the m_providerMutex in CCVideoLayerImpl prevents the
    destruction of WebMediaPlayerClientImpl, thus keeping the frame
    acquired via getCurrentFrame alive until putCurrentFrame is called.
    These functions are only called by the client, and comments are added
    to the interface to better document this.
    
    To prevent a race between load() and getCurrentFrame/putCurrentFrame
    (which are called from different threads) a new m_webMediaPlayerMutex
    to replace part of what the old m_compositingMutex was doing.
    
    * src/WebMediaPlayerClientImpl.cpp:
    (WebKit::WebMediaPlayerClientImpl::~WebMediaPlayerClientImpl):
    (WebKit::WebMediaPlayerClientImpl::load):
    (WebKit::WebMediaPlayerClientImpl::loadInternal):
    (WebKit::WebMediaPlayerClientImpl::setVideoFrameProviderClient):
    (WebKit::WebMediaPlayerClientImpl::getCurrentFrame):
    (WebKit::WebMediaPlayerClientImpl::putCurrentFrame):
    * src/WebMediaPlayerClientImpl.h:
    (WebMediaPlayerClientImpl):
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128082 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Loading