aw: Fix race between first frame draw and view detach causing deadlock.

aw: Fix race between first frame draw and view detach causing deadlock.

If a AwContents.onDetachedFromWindow occurs at simulaneously with
RenderThreadManager::DrawGL, then the following sequence of events can
occur:

* RenderThreadManager::DrawGL creates hardware_renderer_ because a frame
  is ready to be committed to the HardwareRenderer.
* BrowserViewRenderer::OnDetachedFromWindow calls the uncommitted frame
  to be returned to the child compositor.
* RenderThreadManager tries to commit the frame that is just returned,
  leaving it in a state where neither the RenderThreadManager, nor its
  HardwareRenderer has a frame.

Then subsequently when deleting native objects, DeleteHardwareRendererOnUI
does no work, meaning that hardware_renderer_ remains set at the time
that the RenderThreadManager destructor is called, leading to a DCHECK,
or deadlock.

In order to avoid this, we consider RenderThreadManager to have a
frame (and thus need to run the synchronous RenderThread cleanup in
DeleteHardwareRendererOnUI) if it has ever received a frame (stored in
has_received_frame_), rather than if it or hardware_renderer_ currently
has a frame.

In order that BrowserViewRenderer receives the right signal post
deletion of hardware_renderer_, we reset has_received_frame_ when
RenderThreadManager deletes hardware_renderer_, if RenderThreadManager
does not currently have a frame to commit to a new HardwareRenderer
instance.

BUG=668692
Review-Url: https://codereview.chromium.org/2560463002
Cr-Commit-Position: refs/heads/master@{#436672}
(cherry picked from commit ff08fc807243b2317ef1c8b42f3f423496d12a76)

Committed: https://chromium.googlesource.com/chromium/src/+/45dbc1970abbac1c4a48da2ba2075205f397ae09

[Tobias Sargeant, 2016-12-07 11:32:42]

Description was changed from

==========
aw: Fix race between first frame draw and view detach causing deadlock.

If a AwContents.onDetachedFromWindow occurs at simulaneously with
RenderThreadManager::DrawGL, then the following sequence of events can
occur:

* RenderThreadManager::DrawGL creates hardware_renderer_ because a frame
  is ready to be committed to the HardwareRenderer.
* BrowserViewRenderer::OnDetachedFromWindow calls the uncommitted frame
  to be returned to the child compositor.
* RenderThreadManager tries to commit the frame that is just returned,
  leaving it in a state where neither the RenderThreadManager, nor its
  HardwareRenderer has a frame.

Then subsequently when deleting native objects, DeleteHardwareRendererOnUI
does no work, meaning that hardware_renderer_ remains set at the time
that the RenderThreadManager destructor is called, leading to a DCHECK,
or deadlock.

In order to avoid this, we consider RenderThreadManager to have a
frame (and thus need to run the synchronous RenderThread cleanup in
DeleteHardwareRendererOnUI) if it has ever received a frame (stored in
has_received_frame_), rather than if it or hardware_renderer_ currently
has a frame.

In order that BrowserViewRenderer receives the right signal post
deletion of hardware_renderer_, we reset has_received_frame_ when
RenderThreadManager deletes hardware_renderer_, if RenderThreadManager
does not currently have a frame to commit to a new HardwareRenderer
instance.

BUG=668692

Review-Url: https://codereview.chromium.org/2560463002
Cr-Commit-Position: refs/heads/master@{#436672}
(cherry picked from commit ff08fc807243b2317ef1c8b42f3f423496d12a76)
==========

to

==========
aw: Fix race between first frame draw and view detach causing deadlock.

If a AwContents.onDetachedFromWindow occurs at simulaneously with
RenderThreadManager::DrawGL, then the following sequence of events can
occur:

* RenderThreadManager::DrawGL creates hardware_renderer_ because a frame
  is ready to be committed to the HardwareRenderer.
* BrowserViewRenderer::OnDetachedFromWindow calls the uncommitted frame
  to be returned to the child compositor.
* RenderThreadManager tries to commit the frame that is just returned,
  leaving it in a state where neither the RenderThreadManager, nor its
  HardwareRenderer has a frame.

Then subsequently when deleting native objects, DeleteHardwareRendererOnUI
does no work, meaning that hardware_renderer_ remains set at the time
that the RenderThreadManager destructor is called, leading to a DCHECK,
or deadlock.

In order to avoid this, we consider RenderThreadManager to have a
frame (and thus need to run the synchronous RenderThread cleanup in
DeleteHardwareRendererOnUI) if it has ever received a frame (stored in
has_received_frame_), rather than if it or hardware_renderer_ currently
has a frame.

In order that BrowserViewRenderer receives the right signal post
deletion of hardware_renderer_, we reset has_received_frame_ when
RenderThreadManager deletes hardware_renderer_, if RenderThreadManager
does not currently have a frame to commit to a new HardwareRenderer
instance.

BUG=668692

Review-Url: https://codereview.chromium.org/2560463002
Cr-Commit-Position: refs/heads/master@{#436672}
(cherry picked from commit ff08fc807243b2317ef1c8b42f3f423496d12a76)

Committed:
https://chromium.googlesource.com/chromium/src/+/45dbc1970abbac1c4a48da2ba207...
==========

[Tobias Sargeant, 2016-12-07 11:32:44]

Committed patchset #1 (id:1) manually as
45dbc1970abbac1c4a48da2ba2075205f397ae09.