Make i18n live-reload work for default language and write-lock-free if no change #20165
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
wxiaoguang
added
type/bug
skip-changelog
wxiaoguang
force-pushed
the
fix-i18n-reload
branch
from
7cf94da to
b825b98
Compare
wxiaoguang
force-pushed
the
fix-i18n-reload
branch
from
b825b98 to
b4c1230
Compare
…lls within the write-lock time
wxiaoguang
force-pushed
the
fix-i18n-reload
branch
2 times, most recently
from
dec4c73 to
4d3ebce
Compare
wxiaoguang
force-pushed
the
fix-i18n-reload
branch
from
7472f2d to
c3409e7
Compare
wxiaoguang
changed the title
|
The original PR has got 2 L-G-T-M |
GiteaBot
added
the
lgtm/need 2
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
In #20096, I was going to make the live-reload for for fallback default language. But at that time I forgot this detail.
This PR fixes it, makes i18n live-reload work for the fallback default language.
Relation (difference) between #20159:
Allow dev i18n to be more concurrent #20159 uses a more complex approach (more mutexes and more code +100 lines) to lock everything.
It makes the concurrency better in development modeupdate: it seems no difference now.This PR uses a shared mutex to lock everything. No data-race problem, and it's very simple to be maintained in future. In development mode, there is no need for many mutexes, a shared RWMutex should work and in most time there is no write-lock, then no concurrency performance problem, so it's not worth to make code too complex.
These two PRs should have no performance difference for production mode. And they all behave the same in development mode for concurrency accesses.
Personally I usually consider about Return on Investment (ROI) and like simple approaches, so I just put the fix here, let community to choose a preferred approach. Feel free to edit on it / replace it / close it.
Update: This PR describes whether one mutex works, so the variable names are not refactored. The renaming in #20159 (eg:
textMap=>idxToMsgMap) is more clear than before