Fix race condition when enabling vr flinger
The following sequence could result in the surface flinger main thread
getting blocked indefinitely:
1. A vr flinger client creates a surface to be displayed.
2. Vr flinger requests the display from surface flinger.
3. The surface flinger main thread calls
mVrFlinger->GrantDisplayOwnership(), to give the display to vr
flinger. The main thread blocks in HardwareComposer::Enable(), as it
waits for the vr flinger post thread to start running.
4. The vr flinger client from step 1 destroys or hides its display
surface.
5. The post thread, signaled by the main thread in step 3, wakes up,
but since it has no surfaces to draw, it goes back to sleep.
At this point the surface flinger main thread will be stuck
indefinitely, as it waits for the post thread to start running. Since
the post thread has no work to do it'll never start running.
Waiting for the post thread to change state is only necessary when
surface flinger takes the display back from vr flinger, in which case we
need to wait for the post thread to destroy its connection to hardware
composer before continuing. I added separate code to wait for the post
thread in that case, and removed the code to wait in the other cases.
Bug: 72335362
Test: It's pretty hard to hit the timing to expose the race condition.
I locally modified the code to add a sleep in
HardwareComposer::Enable(), after asking the post thread to resume but
before checking to see if it's resumed, and quickly exited vr during the
sleep (on a phone). I confirmed the surface flinger main thread became
stuck waiting for the post thread to resume. Since the code to wait for
the post thread is removed in this CL, the race condition is fixed.
I also tested normal vr usage on phones and standalones.
Change-Id: I75c26be91cf0dd1c910de5443c80cfd18ca629b7
(cherry picked from commit b0ea58eca378cb09a81e3afd9d23d2090d2ba8c3)
1 file changed