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.