-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Tracking Issue for mapped_lock_guards
(MappedMutexGuard
, MappedRwLockReadGuard
, MappedRwLockWriteGuard
)
#117108
Open
2 of 4 tasks
Labels
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
zachs18
added
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
labels
Oct 23, 2023
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Feb 25, 2024
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: rust-lang/libs-team#260 Tracking issue: rust-lang#117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
bors
added a commit
to rust-lang/miri
that referenced
this issue
Feb 25, 2024
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: rust-lang/libs-team#260 Tracking issue: rust-lang/rust#117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
lnicola
pushed a commit
to lnicola/rust-analyzer
that referenced
this issue
Apr 7, 2024
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: rust-lang/libs-team#260 Tracking issue: rust-lang/rust#117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
RalfJung
pushed a commit
to RalfJung/rust-analyzer
that referenced
this issue
Apr 27, 2024
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`. ACP: rust-lang/libs-team#260 Tracking issue: rust-lang/rust#117108 <details> <summary> (Outdated) </summary> `MutexState`/`RwLockState` structs ~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields. </details> The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments. Unresolved question: Are more tests needed?
Is there anything needed to start FCP? Seems it's all implemented and just waiting around. |
I think it's this, there has been activity on zulip about this since that comment. |
From the Zulip activity, it seems like this has nothing to do with mapped lock guards, or am I missing something? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Feature gate:
#![feature(mapped_lock_guards)]
This is a tracking issue for
MappedMutexGuard
,MappedRwLockReadGuard
, andMappedRwLockWriteGuard
.This adds types analogous to
lock_api::MappedMutexGuard
,MappedRwLockReadGuard
,MappedRwLockWriteGuard
) tostd::sync
, and methodsMutexGuard::map
andMutexGuard::try_map
(same for `RwLock*Guard) to create themPublic API
Steps / History
MappedMutexGuard
,MappedRwLockReadGuard
, andMappedRwLockWriteGuard
. #117107Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: