Code review comment for lp:~kdub/mir/compositor-double-start-stop

Since code external to mir is now manipulating the compositor I have concerns about coordinating requests and events involving the compositor. MultiThreadedCompositor doesn't handle multiple starts/stops, because in many cases internal synchronization is not enough; starts/stops need to be coordinated at a higher level and are therefore serialized through our main loop.

Allowing arbitrary code to start/stop the compositor is bound to break Mir. Consider, for example, the dire consequences of restarting the compositor while it is disabled for a display reconfiguration event.

I am not familiar with the code that needs to stop/start the compositor in unity-mir, but we probably need to provide a way (interface) for unity-mir to do what it wants, while we do the right thing internally (go through our main loop).

"Needs Discussion"