Tracking Issue for once_wait

[tgross35]

Feature gate: #![feature(once_wait)]

This is a tracking issue for adding a blocking .wait() method on Once and OnceLock, to allow other threads to synchronize on their completion. This will provide the same interface as once_cell's OnceCell::wait.

Public API

impl Once {
    /// Block the current thread until the `Once` has been initialized.
    fn wait(&self);
    /// Block the current thread until the `Once` has been initialized, ignoring poisoning.
    fn wait_force(&self);
}

impl OnceLock {
    /// Block the current thread until the value is set, then return it.
    fn wait(&self) -> &T;
}

Steps / History

• ACP: Add OnceLock::wait libs-team#405
• Implementation: std: implement the once_wait feature #127567
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Async API (proposed in the ACP): naming, how it works, interaction with other synchronization primitives since e.g. Mutex does not have async methods. This would probably get its own feature gate.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[PhilipDaniels]

This would be very useful, frankly I was surprised when I ran into the problem of get being non-blocking! Pretty-please can this be moved forward to stabilisation?

[orlp]

I don't know about wait_force, but I think wait is clear and uncontroversial enough to stabilize?

[tgross35]

wait_force does mirror call_once_force so it makes sense in that regard. That being said, I think the usecases for wait_force are pretty few and far between outside of implementing OnceLock, and a better solution in the long term will be to use the sync::nonpoison types. So, unless there is a convincing usecase (cc author @joboet), maybe it is better to just leave wait_force internal? (quick usage search doesn't show anything, not entirely surprising for less common nightly API though).

Requesting libs-api to consider stabilizing at least Once::wait and OnceLock::wait, possibly deferring Once::force_wait.

@rustbot label +I-libs-api-nominated

[m-ou-se]

@rfcbot merge

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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.

[tgross35]

^ just to clarify what is in FCP, the meeting notes say

No reason to not also include wait_force

[rfcbot]

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

[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.

This will be merged soon.