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