remove tokio sync primitives #81
Open
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
|
Sorry for the late reply, and thank you for these suggestions on surrealkv. I think they would be useful in the long run. Perhaps we can add them in a future milestone once everything is stable and working as expected, as we do not want to introduce any large breaking change at this time. I'll keep them open for now and maybe add it for a future milestone |
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.
As per #80, this PR will attempt to remove Tokio related sync primitives with
async_mutexandasync_semaphore.Technically speaking, the behavior shouldn't be that much differed, the few things that needs to be taken noticed on is only in fairness guarantee, whether one mutex lock would starve another, and whether or not two mutex lock re-entrancy would cause a live-lock or not.
As for
async_semaphore, I noticed how the "write lock" for the oracle doesn't need a lock at all; it just need a critical section to prevent concurrent access. While I couldn't find any async critical section crate, I think replacing it with a semaphore would better indicate its functionality, hence the change.