start: don't lock setting the state

- setting the handler->state value is atomic on any POSIX implementation since
  we're dealing with an integer (enum/lxc_state_t)
- while the state clients are served it is not possible for lxc_set_state() to
  transition to the next state anyway so there's no danger in moving to the
  next state with clients missing it
- we only care about the list being modified

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

diff --git a/src/lxc/start.c b/src/lxc/start.c
index 9bbf9756a2b06c1180a02f6845b3c9ce706897d2..a7bb6a66531aa8ef9024b2dbfae566562079326b 100644 (file)
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
@@ -341,14 +341,10 @@ static int lxc_serve_state_clients(const char *name,
        struct state_client *client;
        struct lxc_msg msg = {.type = lxc_msg_state, .value = state};
 
-       process_lock();
-
-       /* Only set state under process lock held so that we don't cause
-       *  lxc_cmd_add_state_client() to miss a state.
-        */
        handler->state = state;
        TRACE("Set container state to %s", lxc_state2str(state));
 
+       process_lock();
        if (lxc_list_empty(&handler->state_clients)) {
                TRACE("No state clients registered");
                process_unlock();