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.
This PR adds
crate::util_types::sync::tokio::{AtomicRw, AtomicMutex}
. These are wrappers aroundtokio::sync::{RwLock, Mutex}
and complementtwenty_first::sync::{AtomicRw, AtomicMutex}
which wrap the std library lock types.This PR just introduces the locks without using them in the App yet.
This is extracted from, and is a building block for, a much larger neptune-core PR to follow that reworks lock handling substantially.
These async tokio locks are very similar to the sync counterparts except that:
lock()
andlock_mut()
are async, so would typically be followed by.await
.lock_async()
andlock_async_mut()
are provided. These enable the caller to pass in an async callback fn. Unfortunately the usage/ergonomics is a bit awkward (see doctest examples) and has a runtime cost so in practice I have tended to just uselock_guard()
andlock_guard_mut()
instead.Like the sync types in twenty-first, these types support named locks with lock-event callbacks, which enables detailed loggining/tracing for detecting deadlocks, and lock usage by thread or tokio task.