Replies: 4 comments 6 replies
-
|
In our codebase we often define struct and pass around an Arc<Mutex> in the code, with lock calls all over the place. This is a bad idea for several reasons:
We can easily hold the mutex locked for too long by accident. This is a particularly bad issue in async code. |
Beta Was this translation helpful? Give feedback.
-
|
I am thinking of having something like this: use std::collections::DashMap;
use std::sync::Arc;
#[derive(Clone)]
pub struct SharedMap {
inner: Arc<SharedMapInner>,
}
struct SharedMapInner {
data: DashMap<i32, String>,
}
impl SharedMap {
pub fn new() -> Self {
Self {
inner: Arc::new(SharedMapInner {
data: DashMap::new(),
})
}
}
pub fn insert(&self, key: i32, value: String) {
self.data.insert(key, value);
}
pub fn with_value<F, T>(&self, key: i32, func: F) -> T
where
F: FnOnce(Option<&str>) -> T,
{
func(self.data.get(&key).map(|string| string.as_str()))
}
}Something very similar on same lines even for types which we wrap inside |
Beta Was this translation helpful? Give feedback.
-
|
Let me try to sketch this on my Pool DashMap PR, lets see how the pattern gonna look. |
Beta Was this translation helpful? Give feedback.
-
|
I implemented the above suggestion on the dashmap PR: a1f7dbf , and it kinda look good with strong assertions and no footguns. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
during the review process of #299 + #304 we're coming to the realization that
DashMapshave footgunsmore specifically, holding locks/guards across await points, which compiler/clippy/fmt never warns us about
we need to come up with a sustainable strategy for this
the two main approaches that come to mind:
DashMapCONTRIBUTING.mdthat forces us to have extra discipline and sanity-check PRs as much as possible against these footgunsBeta Was this translation helpful? Give feedback.
All reactions