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 541bce66e43d048d09a36312285e675fddd75f58..4e877356205527de76ce75f99ae96a619a0b6298 100644 (file)
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
@@ -351,14 +351,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();