Rename C++ header files to .hpp Rename all C++ header files (include/**/*-internal.h, src/**/*.h except argpar and msgpack, some headers in tests) to have the .hpp extension. Doing so highlights that we include some C++ header files in some test files still compiled as C. This is ok for now, as the files they include don't actually contain C++ code incompatible with C yet, but they could eventually. This is something we can fix later. Change-Id: I8bf326b6b2946a3e26704f3ef3ac5831bbe9bc26 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Remove ht-cleanup thread The hashtable cleanup thread was introduced to prevent deadlocks happening when the `cds_lfht_destroy()` function was called concurrently with userspace-rcu hashtable resizes. This was fixed in the userspace-rcu project in commit: commit d0ec0ed2fcb5d67a28587dcb778606e64f5b7b83 Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Date: Tue May 30 15:51:45 2017 -0400 Use workqueue in rculfhash That commit makes it so that the `cds_lfht_destroy()` function can safely be called within RCU read-side critical sections. This commit is included in the 0.10 release of urcu. The LTTng-Tools project now has a minimum version dependency on urcu 0.11. Because it's now safe to call `cds_lfht_destroy()` within RCU critical sections, the need for the hash table cleanup thread disappears. This commit replaces all uses of `ht_cleanup_push()` by `lttng_ht_destroy()` and remove all uses and mentions of the ht_cleanup thread. Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I163a281b64a6b3eed62c58515932f71f3b52fea6
Clean-up: sessiond: prepend `the_` to global variable names This avoids name clashes between global variables and local variables or function parameters (notification_thread_handle, for example). This is a step towards enabling -Wshadow. This also helps readability, in my opinion, as it helps quickly spot that some code is using a global variable. Change-Id: Ib0e35ad7efcc54fa88e1900cab3388b98a06b8d9 Signed-off-by: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
sessiond: trigger: run trigger actions through an action executor The `action executor` interface allows the notification subsystem to enqueue work items to execute on behalf of a given trigger. This allows the notification thread to remain responsive even if the actions to execute are blocking (as through the use of network communication). Before this commit, the notification subsystem only handled `notify` actions; handling code for new action types are added as part of the action executor. The existing `notify` action is now performed through the action executor so that all actions can be managed in the same way. This is less efficient than sending the notifications directly, but could be optimized trivially (if it ever becomes a problem) when: - the action is a group containing only a `notify` action, - the action is a `notify` action. Overview of changes to existing code === Managing the new action types requires fairly localized changes to the existing notification subsystem code. The main code paths that are modified are the sites where `evaluation` objects are created: 1) on an object state change (session or channel state changes, see handle_notification_thread_channel_sample and handle_notification_thread_command_session_rotation), 2) on registration of a trigger (see handle_notification_thread_command_register_trigger), 3) on subscription to a condition (see client_handle_message_subscription). To understand the lifetime of most objects involved in a work deferral to the action executor, see the paragraph in notification-thread-internal.h (line 82) to understand the relation between clients and client lists. 1) Object state changes As hinted in the notification_client_list documentation, deferring work on a state change is straight-forward: a reference is taken on a client list and the list is provided to the action executor as part of a work item. Hence, very little changes are made to the the two state-change handling sites beyond enqueuing a work item rather than directly sending a notification. 2) Subscription to a condition A notification client can subscribe to a condition before or after a matching trigger (same condition and containing a notify action) has been registered. If no matching trigger were registered, no client list exists and there is nothing to do. If a matching trigger existed, a client list (which could be empty) will already exist and the client is simply added to the client list. However, it is important to evaluate the condition for the client (as the condition could already be true) and send the notification to that client only and not to all clients in the list. Before this change, since everything was done in the same thread, a temporary list containing only the newly-subscribed client was created on the stack and the notification was sent/queued immediately. After sending the condition, the client was removed from the temporary list and added to the "real" client list. This strategy cannot be used with the action executor as the "temporary" client list must exist beyond the scope of the function. Moreover, the notification subsystem assumes that clients are in per-condition client lists and that they can safely be destroyed when they are not present in any list. Fortunately, here we know that the action to perform is to `notify` and nothing else. The enqueuing of the notification is performed "in place" by the notification thread without deferring to the action executor. 3) Registration of a trigger When a client subscribes to a condition, the current state of that condition is immediately evaluated. If the condition is true (for instance, a channel's buffer are filled beyond X% of their capacity), the action associated with the trigger is executed right away. This path requires little changes as a client list is created when a trigger is registered. Hence, it is possible to use the client list to defer work as is done in `1`. 4) Trigger registration Since the `notify` action was the only supported action type, the notification subsystem always created a client list associated with the new trigger's condition. This is changed to only perform the creation (and publication) of the client list if the trigger's action is (or contains, in the case of a group) a `notify` action. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I43b54b93c1244591aeff6e0d0fa8076c7b5e0c50
Revert "sessiond: trigger: run trigger actions through an action executor" This reverts commit d1ba29d290281cf72ca3ec7b0222b336c747e925. Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com> Change-Id: I70d57fef86aea94a590720689af751e2554184d0
sessiond: trigger: run trigger actions through an action executor The `action executor` interface allows the notification subsystem to enqueue work items to execute on behalf of a given trigger. This allows the notification thread to remain responsive even if the actions to execute are blocking (as through the use of network communication). Before this commit, the notification subsystem only handled `notify` actions; handling code for new action types are added as part of the action executor. The existing `notify` action is now performed through the action executor so that all actions can be managed in the same way. This is less efficient than sending the notifications directly, but could be optimized trivially (if it ever becomes a problem) when: - the action is a group containing only a `notify` action, - the action is a `notify` action. Managing the new action types requires fairly localized changes to the existing notification subsystem code. The main code paths that are modified are the sites where `evaluation` objects are created: - on an object state change (session or channel state changes, see handle_notification_thread_channel_sample and handle_notification_thread_command_session_rotation), - on registration of a trigger (see handle_notification_thread_command_register_trigger), - on subscription to a condition (see client_handle_message_subscription). To understand the lifetime of most objects involved in a work deferral to the action executor, see the paragraph in notification-thread-internal.h (line 82) to understand the relation between clients and client lists. Overview of changes === Object state changes Change-Id: I23290e94d98e781992661f0aee88de9986ed274f --- As hinted in the notification_client_list documentation, defering work on a state change is straight-forward: a reference is taken on a client list and the list is provided to the action executor as part of a work item. Hence, very little changes are made to the the two state-change handling sites beyond enqueuing a work item rather than directly sending a notification. Subscription to a condition --- A notification client can subscribe to a condition before or after a matching trigger (same condition and containing a notify action) has been registered. When a client subscribes to a condition, it is a added to a corresponding "client list" Registration of a trigger --- When a client subscribes to a condition, the current state of that condition is immediately evaluated. If the condition is true (for instance, a channel's buffer are filled beyond X% of their capacity), TODO: Change-Id: I7f9bc197715c9ca008a4f1fcd4c86e01b6252dce Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Move to kernel style SPDX license identifiers The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. See https://spdx.org/ids-how for details. Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Change-Id: I62e7038e191a061286abcef5550b58f5ee67149d Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Sessiond timer thread This new thread allows to handle timers in the session daemon. The structure is the same as the consumer-timer thread. For now it does not perform any action, but it will be used by the session rotation feature. Signed-off-by: Julien Desfossez <jdesfossez@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Sessiond rotation thread This thread is responsible to receive the notifications from the consumers that a channel has finished its rotation and perform the rename of the chunk ready to be processed by the client when all the channels of a session have completed their rotation. Signed-off-by: Julien Desfossez <jdesfossez@efficios.com> Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Health check: implement health check query in sessiond and consumerd At this stage, tests/regression/tools/health/health_check queries sessiond and consumerd with the new API, however, the scripts using this program have not yet been changed, and are therefore expected to fail. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>