-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Mutex guard lock ref recovery methods #3928
Conversation
I think having a method like this makes sense. Some comments:
|
I tried this. But the guard returned from Is it OK to add that new generic (with the default, like for
Good point. I will address your other comments. I'm inclined to split the |
Oh: another possible colour for this bikeshed. |
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
c3af44d
to
5aa6958
Compare
I split this off - see #3930. Thanks.
I was wrong when I said that
Thanks. I prefer to have a self-contained function as it avoids the example being cluttered with setup code, so I have left this as-is.
Done. Is there some automatic way to run rustfmt on doctests? I resorted to cut-and-paste plus this rune: |
Eh, I prefer |
Cool, no repainting needed then. Anything else you'd like me to do to this MR? |
I think it seems ok. I'll wait for the americans to get a chance to review it though. |
Motivation
There are various situations where it is useful to be able to recover
&Mutex
from aMutexGuard
. One of them is condition variables (see #3892 and my new async-condvar-fair crate) but there are other possibilities.Solution
Broadly, for the applicable guard types, and where possible:
(Mutatis mutandis for the various mutex types - varies eg for
Owned
andRwLock
.)In #3741 a method was proposed to convert the guard into the mutex reference. Obtaining a borrow is strictly more general, and is what is implemented in
parking_lot
andsmol
for their mutex types.Open questions
Are these the best names?
parking_lot
usesfn mutex()
for its mutex type but does not provide these facilities for its rwlocks.smol
useslock()
source()
which is more general, leading to less variation betweenMutex
andRwLock
.Was I right to use#[tokio::main] async fn main(){...}
for my doctests? The contribution guide suggests something involvingblock_on
but the other tests inmutex.rs
used#[tokio::main]
so I chose that.I wasn't sure whether to#
out theuse
s at the top of the doctests. I find them noisy here - in this particular case the intended types are extremely obvious.I have skippedThe (straightforward portions of) the corresponding feature forRwLockReadGuard
andRwLockWriteGuard
. This is not because I think they wouldn't be useful, but those structs contain references to pieces of the rwlock, not the whole rwlock, and I wasn't sure how to recover a suitable reference (or whether that's even possible).RwLock
is now RwLock guard lock ref recovery methods, owned guards #3930.