-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 std::sync::Once poisoning #33577
Comments
The tracking issue for once_poison was noted as rust-lang#31688 which was closed, so it now points to the new rust-lang#33577.
update tracking issue for once_poison The tracking issue for once_poison was noted as rust-lang#31688 which was closed, so it now points to the new rust-lang#33577.
This issue is primarily about the |
EDIT: nevermind |
This naming seems inconsistent: Could they both be |
Relevant: #43448 contains discussion of whether forking a process should cause poisoning of various synchronization primitives. TLDR: An option is to make it so that if you fork while a |
Triage: no changes here that I'm aware of. |
Yes, the "poison on fork" proposal should be considered dead for the time being. The discussion in this issue can safely ignore that proposal. |
I think this API is well designed and worth stabilizing. Note that parking_lot uses a difference @rfcbot fcp merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Apart from consistency I find |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Should this API stabilize after successful FCP or do I misunderstand stabilization process? |
Someone needs to submit a stabilization PR for this feature. |
@Amanieu OK, I decided to become that someone. :) Thanks for clarifying! |
…ou-se Stabilize poison API of Once, rename poisoned() This stabilizes: * `OnceState` * `OnceState::is_poisoned()` (previously named `poisoned()`) * `Once::call_once_force()` `poisoned()` was renamed because the new name is more clear as a few people agreed and nobody objected. Closes rust-lang#33577 Notes: * I'm not entirely sure it's supposed to be 1.51, LMK if I did it wrong * I failed to run tests locally, so we will have to leave it to bors or someone else can try
…ou-se Stabilize poison API of Once, rename poisoned() This stabilizes: * `OnceState` * `OnceState::is_poisoned()` (previously named `poisoned()`) * `Once::call_once_force()` `poisoned()` was renamed because the new name is more clear as a few people agreed and nobody objected. Closes rust-lang#33577 Notes: * I'm not entirely sure it's supposed to be 1.51, LMK if I did it wrong * I failed to run tests locally, so we will have to leave it to bors or someone else can try
This tracks the
once_poison
feature, which currently covers the following things understd::sync::once
:OnceState
, a struct describing the poisonedness of aOnce
OnceState::poisoned
, which reveals said poisonednessOnce::call_once_force
, which is likecall_once
but ignores poisoningThe text was updated successfully, but these errors were encountered: