-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Implementation: #[feature(sync_nonpoison)]
, #[feature(nonpoison_mutex)]
#144022
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
base: master
Are you sure you want to change the base?
Conversation
b45b493
to
deda5c5
Compare
This comment has been minimized.
This comment has been minimized.
deda5c5
to
19b1a2c
Compare
This comment has been minimized.
This comment has been minimized.
19b1a2c
to
a259232
Compare
This comment has been minimized.
This comment has been minimized.
e130930
to
804d305
Compare
804d305
to
b615348
Compare
r? tgross35 |
35fc4df
to
71395b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good to me, most comments here are related to docs. This will need some history cleanup, there isn't any need to preserve the current state of #134663 in history (I assume this was just done for now to show what changed since then)
if mem::needs_drop::<T>() { | ||
drop(old) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if
statement does not do anything. The original implementation uses needs_drop
to decide whether to utilize replace
, while this implementation will call replace
unconditionally, potentially causing some memcpy
overhead for trivially drop types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh that makes sense, will change!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you check if this makes sense?
e0ce960
to
dc5f86f
Compare
dc5f86f
to
0e52413
Compare
This PR modifies |
0e52413
to
19ab767
Compare
|
||
/// A lock could not be acquired at this time because the operation would otherwise block. | ||
#[unstable(feature = "sync_nonpoison", issue = "134645")] | ||
pub struct WouldBlock; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better if we make the WouldBlock
constructor private? So that if we add new fields to it later, it would not cause breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would lean on the side of no since TryLockError
in the poison
module has been around since 1.0 and it has never needed more variants than Poisoned
and WouldBlock
?
Adds the equivalent `nonpoison` types to the `poison::mutex` module. These types and implementations are gated under the `nonpoison_mutex` feature gate. Co-authored-by: Aandreba <[email protected]>
This commit simply helps discern the actual changes needed to test both poison and nonpoison locks.
Adds tests for the `nonpoison::Mutex` variant by using a macro to duplicate the existing `poison` tests. Note that all of the tests here are adapted from the existing `poison` tests.
☔ The latest upstream changes (presumably #144488) made this pull request unmergeable. Please resolve the merge conflicts. |
Blesses the ui tests that now have a name conflicts (because these types no longer have unique names). The full path distinguishes the different types. Co-authored-by: Trevor Gross <[email protected]>
Also cleans up some other test documentation.
19ab767
to
ac48789
Compare
Continuation of #134663
Tracking Issue: #134645
This PR implements a new
sync/nonpoison
module, as well as thenonpoison
variant of theMutex
lock.There are 2 main changes here, the first is the new
nonpoison::mutex
module, and the second is themutex
integration tests.For the
nonpoison::mutex
module, I did my best to align it with the current state of thepoison::mutex
module. This means that several unstable features (mapped_lock_guards
,lock_value_accessors
, andmutex_data_ptr
) are also in the newnonpoison::mutex
module, under their respective feature gates. Everything else in that file is under the correct feature gate (#[unstable(feature = "nonpoison_mutex", issue = "134645")]
).Everything in the
nonpoison::mutex
file is essentially identical in spirit, as we are simply removing the error case from the originalpoison::mutex
.The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always
unwrap
ped.I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the othernonpoison
locks when they eventually get implemented, but I'll leave that for a later discussion.