Skip to content

[naga]: Switch off of LazyLock to once_cell::racy::OnceBox #7587

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: trunk
Choose a base branch
from

Conversation

bushrat011899
Copy link
Contributor

@bushrat011899 bushrat011899 commented Apr 21, 2025

Connections

Description

  • Added a custom alternative to LazyLock, RacyLock, which uses AtomicPtr internally. This type is a drop-in replacement for LazyLock, but it trades in blocking for potentially leaking the initialized value in cases where multiple threads attempt to initialize. The type is public but in a private module to prevent external use.
  • Removed instances of LazyLock and replaced them with RacyLock.
  • Removed hlsl_out, wgsl_out, and msl_out from the extern crate std; statement, decoupling those features from explicit std usage.

Testing

  • CI

Squash or Rebase?

Squash

Checklist

  • Run cargo fmt.
  • Run taplo format. N/A
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • If this contains user-facing changes, add a CHANGELOG.md entry. N/A

Notes

This addition includes two unsafe blocks in order to dereference the pointer stored within an internal AtomicPtr. I considered this preferable to bringing in a 3rd party dependency, such as spin.

I also chose to not offer a feature to switch back to std::sync::LazyLock, since such a feature would increase Naga's complexity, and risk stagnating unsafe code.

Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea of the change is fine, but I would rather not have the unsafe be our responsibility - once_cell::racy::OnceBox exists and is already in-tree - can we build our RacyLock on top of that, we can do it in entirely safe code?

@bushrat011899
Copy link
Contributor Author

I think the idea of the change is fine, but I would rather not have the unsafe be our responsibility - once_cell::racy::OnceBox exists and is already in-tree - can we build our RacyLock on top of that, we can do it in entirely safe code?

Oh I didn't realise that was the case, and I wasn't familiar with OnceBox either! That's a much better fit, I'll update this PR later tonight to remove the unsafe code and use that instead.

@bushrat011899
Copy link
Contributor Author

Switched to OnceBox as discussed, less code and no unsafe. Didn't even need to add the race feature haha

Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nits

bushrat011899 and others added 3 commits April 23, 2025 09:48
Co-Authored-By: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Co-Authored-By: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Co-Authored-By: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
@ErichDonGubler ErichDonGubler changed the title [naga]: Switch off of LazyLock to a custom RacyLock [naga]: Switch off of LazyLock to once_cell::racy::OnceBox Apr 23, 2025
@cwfitzgerald cwfitzgerald self-assigned this Apr 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants