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

> If unity-mir was the sole consumer of the Compositor::start and
> Compositor::stop, then it could save the compositor running state itself.
> However I don't believe that is the case, is it?

I'm *still* not convinced that unity-mir should be calling Compositor::start()/stop() in this case it smells of being a workaround for a Mir bug.

If justified, it would be possible for unity-mir to track the state correctly by overriding Compositor::start()/stop() and only calling the base version when appropriate.

> If you supplied a "running" method to check for the compositor thread state,
> then unity-mir would have sufficient information to make the right decision.

No it couldn't: start()/stop() could be called on another thread after running() returned.

> However I do also believe a library should try to recover gracefully from mis-
> use whenever possible.

I think that a clearly diagnosable and immediate crash is preferable to ignoring errors only to fail in an obscure way later.

> Calling start() twice shouldn't crash.

That is a matter on which reasonable minds can (and do) differ. But it would be moot if there were no need to call it in USC or unity-mir.