Forking from  issue 786448 . Needs investigation.

c#6:
"""
I have a theory for how the context loss on compositor causes the dcheck to fail:
1. Compositor context uses TryUpdateThreadSafe on worker context for polling sync tokens via IsSyncTokenSignaled.
2. TryUpdateThreadSafe updates the worker context's last_state_ which has an error. It posts context loss callback (OnGpuControlLostContext) to worker thread. This callback is responsible for calling share group Lose.
3. Meanwhile, GenerateSyncTokenHelper is called on worker context on worker thread.
4. GenUnverifiedSyncToken returns an empty sync token because OrderingBarrier doesn't do anything. CommandBufferProxyImpl flushed_fence_sync_ isn't updated so IsFenceSyncFlushed returns false.
5. DCHECK fails because sync token is empty and GetGraphicsResetStatusKHR returns no error. The latter looks at share group IsLost which hasn't been set yet because the callback in 2 is pending.
"""

c#7:
"""
I think (2) breaks some assumptions, which is that all contexts in the same share group are lost at the same time. Problem is that we need to run the callback for that, and we can't run the callback on a thread that doesn't have the lock. Maybe we could take the lock in that case and calling the callback reentrantly, but with the risk of blocking the calling thread in that edge case (maybe ok? But could we cause deadlocks?).

(4) feels a bit wrong, I've been meaning to look at how we handle lost state wrt sending messages. I feel like we're being overly pessimistic and that hurts more than it helps. But either way, it would only paper over the underlying issue.
"""

c#9:
"""
I ran over a million or so permutations (1/4 of total permutations) using perry.py and can't repro this any more. I think it might be because crrev.com/826007 makes GenSyncToken always return a non-empty sync token.

I'll remove the DCHECK because it doesn't make sense any more.

But we still need to be careful about not failing commands based on command buffer proxy's last_state_.error as it can be out of sync with the share group's lost state. We don't want clients to see calls fail but GetGraphicsResetStatusKHR return no error at the same time.
"""