Comment 2 for bug 1528384

Looking at the stack traces, it seems to generally happen on phones when the screen tries to turn on due to a proximity event from dbus/powerd.

The only reasonable explanation I can find is due to the fact that MultiThreadedCompositor::start/stop() are not locked. Instead they use atomic compare/exchange so are written assuming stop/start are called from the same thread. If stop and start are not called from the same thread under USC then it's possible we're trying to start the compositor while it's still stopping. And that might result in us waiting for incorrect CompositingFunctors.