plugin: Introduce explicit locking on the root runner operations #2115
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
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.
Follow up of #2094
The bug in #2094 was fixed by #2096, but the problem of race conditions being prone to occur because the root runner is shared by multiple goroutines remains. Ideally, "Do not communicate by sharing memory; instead, share memory by communicating", but this would require significant design changes.
As a compromise, this PR changes the plugin API to acquire an explicit lock when performing operations on the root runner. This makes race conditions less likely to occur if side-effective operations are unintentionally introduced into the Runner API.
On the other hand, if multiple plugins perform frequent operations on the root runner, there is a risk of performance degradation. At least in most current cases, this is called only once during the initialization phase to obtain the contents of the
providerblock, so I suspect this problem will not be apparent.In the future, we will need to redesign the API in conjunction with terraform-linters/tflint-plugin-sdk#193.