Wait until old ComposerClient is fully destroyed before recreating
Possible race condition where EventCallbacks are registered before old implementation deregisters on destruction. Stems from fact that strong pointer destruction does not mean the object has completely run its destructor method Bug: 135210708 Test: build, boot, VtsHalGraphicsComposerV2_1TargetTest Change-Id: I0851f1197d8341854f5bdac5fbb08553fc32b710
This commit is contained in:
parent
5927a9b1f1
commit
bf967c9bdb
1 changed files with 3 additions and 5 deletions
|
@ -109,12 +109,10 @@ class ComposerImpl : public Interface {
|
|||
// inverted (create and then destroy). Wait for a brief period to
|
||||
// see if the existing client is destroyed.
|
||||
ALOGD("waiting for previous client to be destroyed");
|
||||
mClientDestroyedCondition.wait_for(
|
||||
lock, 1s, [this]() -> bool { return mClient.promote() == nullptr; });
|
||||
if (mClient.promote() != nullptr) {
|
||||
mClientDestroyedCondition.wait_for(lock, 1s,
|
||||
[this]() -> bool { return mClient == nullptr; });
|
||||
if (mClient != nullptr) {
|
||||
ALOGD("previous client was not destroyed");
|
||||
} else {
|
||||
mClient.clear();
|
||||
}
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in a new issue