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(store/v2): Assume SS/SC backends are concurrent by default #17990

Closed
testinginprod opened this issue Oct 6, 2023 · 2 comments
Closed

feat(store/v2): Assume SS/SC backends are concurrent by default #17990

testinginprod opened this issue Oct 6, 2023 · 2 comments
Assignees
Labels

Comments

@testinginprod
Copy link
Contributor

In order to simplify the store package, we should assume all SS/SC backends are thread safe by default, the implementation should handle concurrency itself in such a way to achieve the best lock granularity.

@github-actions github-actions bot added the needs-triage Issue that needs to be triaged label Oct 6, 2023
@tac0turtle tac0turtle added C:Store and removed needs-triage Issue that needs to be triaged labels Oct 6, 2023
@alexanderbez alexanderbez linked a pull request Oct 6, 2023 that will close this issue
20 tasks
@alexanderbez alexanderbez removed a link to a pull request Oct 6, 2023
20 tasks
@alexanderbez
Copy link
Contributor

The default root store implementation uses a mutex lock. What exactly is the rationale for the underlying SS backends to have additional locks? It seems to me that we should rely on the storage engine's concurrency mechanism.

@testinginprod
Copy link
Contributor Author

@alexanderbez this was already addressed in: https://github.com/cosmos/cosmos-sdk/pull/17995/files#diff-1d3af25f440ffa070f28b311f269f2ed08b17dc88847a2768f727692930926a5L1

closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants