Use a more efficient Once on platforms without threads

[joboet]

The current implementation uses an atomic queue and spins rather than panicking when calling call_once recursively. Since concurrency is not supported on platforms like WASM, Once can be implemented much more efficiently using just a single non-atomic state variable.

[rustbot]

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[thomcc]

Sure, this seems fine. Sorry for the delay

@bors r+

[bors]

📌 Commit f9b5684 has been approved by thomcc

It is now in the queue for this repository.

[bjorn3]

Does this use the existing multi-threaded Once when the atomics target feature is enabled for wasm?

[joboet]

Does this use the existing multi-threaded Once when the atomics target feature is enabled for wasm?

Yes exactly. It shares the futex-based implementation also used by Linux.

[bors]

⌛ Testing commit f9b5684 with merge 7ab8038...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing 7ab8038 to master...

[rust-timer]

Finished benchmarking commit (7ab8038): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.9%, 1.1%]	2
Regressions ❌ (secondary)	2.2%	[2.0%, 2.6%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[0.9%, 1.1%]	2

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-3.1%, -1.4%]	12
All ❌✅ (primary)	-	-	0

[lqd]

This is common noise on these benchmarks: the opposite of the previous commit's improvements.

@rustbot label: +perf-regression-triaged