commands: remove mutex from state client list #2189
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I was thinking about the locking here yesterday and it dawned on me that we actually don't need this at all: - possible contention between traversing list to send states to state clients and adding new state clients to the list: It is the command handler that adds new state clients to the state client list. The command handler and the code that actually sends out the container states run in the same process so there's not contention and thus no locking needed. - adding state clients to the list from multiple threads: The command handler itself is single-threaded so only one thread's request can be served at the same time so no locking is needed. - sending out the state to state clients via the command handler itself: The state client also adds and removes state clients from the state client list so there's no locking needed. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was thinking about the locking here yesterday and it dawned on me that we
actually don't need this at all:
and adding new state clients to the list:
It is the command handler that adds new state clients to the state client
list. The command handler and the code that actually sends out the container
states run in the same process so there's not contention and thus no locking
needed.
The command handler itself is single-threaded so only one thread's request can
be served at the same time so no locking is needed.
The state client also adds and removes state clients from the state client
list so there's no locking needed.
Signed-off-by: Christian Brauner christian.brauner@ubuntu.com