зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1389759 - Fix GPUProcessManager::EnsureGPUReady how did not guarantee the GPU process state is consistent. r=rhunt
GPUProcessManager::EnsureGPUReady promises that its state will be consistent after returning. Either the GPU process is ready to be used, or there is no GPU process at all. In the case it is attempted to synchronously initialize the GPUChild with the device data and failed, it broke that promise. This is because the GPU process was still setup, but we weren't going to use it. This became a problem with the CompositorManagerChild because it uses the process token as an identifier, and it should have been reset to 0 in this case. Now if GPUChild::EnsureGPUReady (the initialization step) fails, we disable the GPU process entirely. This ensures our internal state is consistent and the callers expectations are upheld.
This commit is contained in:
Родитель
6c6e2604c1
Коммит
8a37b15344
|
@ -205,8 +205,17 @@ GPUProcessManager::EnsureGPUReady()
|
|||
}
|
||||
}
|
||||
|
||||
if (mGPUChild && mGPUChild->EnsureGPUReady()) {
|
||||
return true;
|
||||
if (mGPUChild) {
|
||||
if (mGPUChild->EnsureGPUReady()) {
|
||||
return true;
|
||||
}
|
||||
|
||||
// If the initialization above fails, we likely have a GPU process teardown
|
||||
// waiting in our message queue (or will soon). We need to ensure we don't
|
||||
// restart it later because if we fail here, our callers assume they should
|
||||
// fall back to a combined UI/GPU process. This also ensures our internal
|
||||
// state is consistent (e.g. process token is reset).
|
||||
DisableGPUProcess("Failed to initialize GPU process");
|
||||
}
|
||||
|
||||
return false;
|
||||
|
|
Загрузка…
Ссылка в новой задаче