-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for lock_value_accessors
#133407
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
Comments
I think the name |
I am OK with |
Would it make sense to have a get_copied()? Or even a get_with which accepts a closure to retrieve the return value? This could cover clone and copy types as well as allow to return a value from a nested field like |
@marmeladema: I am in favor of adding a set of more generalized APIs: impl<T> Mutex<T>
where
T: ?Sized,
{
pub fn with_mut<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
where
F: FnOnce(&mut T) -> R,
{
match self.lock() {
Ok(mut guard) => Ok(f(&mut guard)),
Err(_) => Err(PoisonError::new(f)),
}
}
}
impl<T> RwLock<T>
where
T: ?Sized,
{
pub fn with<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
where
F: FnOnce(&T) -> R,
{
match self.read() {
Ok(guard) => Ok(f(&guard)),
Err(_) => Err(PoisonError::new(f)),
}
}
pub fn with_mut<F, R>(&self, f: F) -> Result<R, PoisonError<F>>
where
F: FnOnce(&mut T) -> R,
{
match self.write() {
Ok(mut guard) => Ok(f(&mut guard)),
Err(_) => Err(PoisonError::new(f)),
}
}
} These new APIs have the advantage of being explicit about locking scopes. Traditional APIs rely on the destructing of lock guard objects, which is not visually apparent to users, increasing the risk of locks being held for longer than necessary. With the new APIs, the chances of unintentionally holding locks for extended periods can be reduced. A new ACP has been accepted for non-poisoning types: rust-lang/libs-team#497. |
…atrieb Add value accessor methods to `Mutex` and `RwLock` - ACP: rust-lang/libs-team#485. - Tracking issue: rust-lang#133407. This PR adds `get`, `set` and `replace` methods to the `Mutex` and `RwLock` types for quick access to their contained values. One possible optimization would be to check for poisoning first and return an error immediately, without attempting to acquire the lock. I didn’t implement this because I consider poisoning to be relatively rare, adding this extra check could slow down common use cases.
Rollup merge of rust-lang#133406 - EFanZh:lock-value-accessors, r=Noratrieb Add value accessor methods to `Mutex` and `RwLock` - ACP: rust-lang/libs-team#485. - Tracking issue: rust-lang#133407. This PR adds `get`, `set` and `replace` methods to the `Mutex` and `RwLock` types for quick access to their contained values. One possible optimization would be to check for poisoning first and return an error immediately, without attempting to acquire the lock. I didn’t implement this because I consider poisoning to be relatively rare, adding this extra check could slow down common use cases.
…atrieb Add value accessor methods to `Mutex` and `RwLock` - ACP: rust-lang/libs-team#485. - Tracking issue: rust-lang#133407. This PR adds `get`, `set` and `replace` methods to the `Mutex` and `RwLock` types for quick access to their contained values. One possible optimization would be to check for poisoning first and return an error immediately, without attempting to acquire the lock. I didn’t implement this because I consider poisoning to be relatively rare, adding this extra check could slow down common use cases.
Sorry if this has been mentioned elsewhere, maybe it's obvious but it wasn't clear to me - is there a reason that pub fn get_cloned(&self) -> Result<T, PoisonError<T>>
where
T: Clone,
{
match self.lock() {
Ok(guard) => Ok((*guard).clone()),
Err(e) => Err(PoisonError::new((*e.into_inner()).clone())),
}
} |
@arvidfm: I am not sure that whether calling |
@EFanZh Is it worth optimising for that case, considering that the user was already prepared to pay the cost of the clone to begin with by calling As it stands, the signature breaks the pattern of |
@EFanZh I could imagine having poison handling in some places, while in other places just wanting to get a copy of the current value regardless. Or perhaps wanting to clone the inner value, but in the case of poisoning wanting to do something to the cloned value before returning it. I'm not saying I think it's a particularly common use case or anything, I just think that cloning on the error path would make the method more general and more useful for those kinds of edge cases. And to me at least it doesn't seem worth breaking symmetry with other similar methods for the sake of optimising the error path, especially when the optimisation is removing a call that the user already opted into by virtue of calling a cloning method to begin with. |
Uh oh!
There was an error while loading. Please reload this page.
Feature gate:
#![feature(lock_value_accessors)]
This is a tracking issue for feature
lock_value_accessors
.Public API
Steps / History
get
,set
andreplace
methods toMutex
andRwLock
libs-team#485Mutex
andRwLock
#133406Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: