Fix: semaphore semantics are expected from notification command eventfd

The notification command queue currently expects eventfd() to
behave according to EFD_SEMAPHORE semantics. Right now, multiple
commands could be enqueued and reading the eventfd resets its
internal counter to 0. This will cause the notification thread
to never process the next command.

EFD_SEMAPHORE will ensure that poll/epoll signals that there is
info available for reading until the eventfd's internal counter
returns to 0.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>

diff --git a/src/bin/lttng-sessiond/notification-thread.c b/src/bin/lttng-sessiond/notification-thread.c
index e0937d8e58eb577d2f088968d7a16299fe5db4c8..70ab7bb5fceb974c0acd04a8003ae453ea5a2efe 100644 (file)
--- a/src/bin/lttng-sessiond/notification-thread.c
+++ b/src/bin/lttng-sessiond/notification-thread.c
@@ -209,7 +209,7 @@ struct notification_thread_handle *notification_thread_handle_create(
        }
 
        /* FIXME Replace eventfd by a pipe to support older kernels. */
-       handle->cmd_queue.event_fd = eventfd(0, EFD_CLOEXEC);
+       handle->cmd_queue.event_fd = eventfd(0, EFD_CLOEXEC | EFD_SEMAPHORE);
        if (handle->cmd_queue.event_fd < 0) {
                PERROR("eventfd notification command queue");
                goto error;