Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: make Lipgloss Style thread-safe #139

Closed
wants to merge 2 commits into from
Closed

feat: make Lipgloss Style thread-safe #139

wants to merge 2 commits into from

Conversation

muesli
Copy link
Contributor

@muesli muesli commented Oct 5, 2022

Since we had a few reports about concurrently accessing base style definitions, I figured one solution would be making Style's rules map thread-safe. While it's an elegant solution, it is a trade-off: it guards against crashes from concurrent access, but that obviously slows down access by a tiny bit. I don't think the impact is too bad, though, and not crashing is always nice.

go test -bench=. -benchtime=30s

Before change:

goos: linux
goarch: amd64
pkg: github.com/charmbracelet/lipgloss
cpu: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
BenchmarkStyleRender-4           7875594              4555 ns/op
PASS

With sync.map:

goos: linux
goarch: amd64
pkg: github.com/charmbracelet/lipgloss
cpu: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
BenchmarkStyleRender-4           7017492              5167 ns/op
PASS

@muesli
Copy link
Contributor Author

muesli commented Oct 5, 2022

Here's one thing I dislike about my own change: this doesn't protect the value member of the Style. This is typically not a problem, because we operate on a copy of Style in critical situations. I can already see future changes invalidating this argument, though, and we would suddenly have to start debugging similar crashes again.

With that being said, maybe an exclusive sync.RWMutex is the better solution for our problem?

@meowgorithm
Copy link
Member

meowgorithm commented Oct 5, 2022

We’re deprecating SetString in the instances branch, right? If so, that would deprecate value here, so maybe that’s a non-issue.

This this is great. It doesn’t appear to impact performance much and the thread-safety it brings is a pretty big deal.

This eliminates the chance of ever accessing an uninitialized map,
which caused a few bugs in the past. The performance impact of this
seems barely measurable.
aymanbagabas added a commit that referenced this pull request Mar 28, 2024
Use an int to store property existence and style struct fields to store
the actual values for each non-bool property.

Fixes: #139
Fixes: #141
aymanbagabas added a commit that referenced this pull request Mar 28, 2024
Use an int to store property existence and style struct fields to store
the actual values for each non-bool property.

Fixes: #139
Fixes: #141
aymanbagabas added a commit that referenced this pull request Mar 28, 2024
Use an int to store property existence and style struct fields to store
the actual values for each non-bool property.

Fixes: #139
Fixes: #141
aymanbagabas added a commit that referenced this pull request Mar 28, 2024
Use an int to store property existence and style struct fields to store
the actual values for each non-bool property.

Fixes: #139
Fixes: #141
aymanbagabas added a commit that referenced this pull request May 2, 2024
Use an int to store property existence and style struct fields to store
the actual values for each non-bool property.

Fixes: #139
Fixes: #141
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants