Rust: Tracking issue for std::sync::Once poisoning

[durka]

This tracks the once_poison feature, which currently covers the following things under std::sync::once:

• [ ] OnceState, a struct describing the poisonedness of a Once
• [ ] OnceState::poisoned, which reveals said poisonedness
• [ ] Once::call_once_force, which is like call_once but ignores poisoning

[brson]

This issue is primarily about the call_once_force method. Once implements poisoning, and this method is how you get around a poisoned Once.

[frewsxcv]

~Anyone have insight why poisoned is not just a method on Once?~

EDIT: nevermind

[dtolnay]

This naming seems inconsistent:

• Mutex::is_poisoned
• OnceState::poisoned

Could they both be is_poisoned since that one is stable already? Or is poisoned better enough that we should deprecate and rename the one on Mutex?

[joshlf]

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 Once is in use, thus invalidating it, that Once becomes poisoned.

[steveklabnik]

Triage: no changes here that I'm aware of.

[sanmai-NL]

43448 was closed. @joshlf Can this issue be expedited, without discussing more than one scenario in which the state should be poisoned?

[joshlf]

Yes, the "poison on fork" proposal should be considered dead for the time being. The discussion in this issue can safely ignore that proposal.

[Amanieu]

I think this API is well designed and worth stabilizing. Note that parking_lot uses a difference OnceState, but I think the current one we have in libstd is fine as it is.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• [x] @Amanieu
• [ ] @SimonSapin
• [x] @dtolnay
• [x] @sfackler
• [ ] @withoutboats

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.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[Kixunil]

Apart from consistency I find is_poisoned more clear than poisoned. The latter sounds a bit like a constructor that creates a poisoned instance.

[rfcbot]

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.