-
Notifications
You must be signed in to change notification settings - Fork 2
Fall back to Rc on targets without atomics #46
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
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #46 +/- ##
==========================================
- Coverage 90.90% 90.89% -0.02%
==========================================
Files 55 55
Lines 7456 7456
==========================================
- Hits 6778 6777 -1
- Misses 678 679 +1
🚀 New features to boost your workflow:
|
redboltz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR.
I’ve been thinking about whether automatic detection and switching is really the right choice.
#[cfg(target_has_atomic = "ptr")]
Arc uses A as Atomic, but it silently falls back to a non-atomic reference counter. That’s my first concern.
In practice, this is fine because most multi-threaded environments provide atomic operations for ptr.
In other words, if #[cfg(not(target_has_atomic = "ptr"))] is true, we can assume the environment is single-threaded.
`alloc::sync::Arc` is unavailable on targets without atomics, such as ESP32-C3, which is riscv32imc. In this case, use `Rc` instead, and make the user responsible for synchronization.
Yes, that is my thought as well. |
|
It seems that github actions' environmental issue is happened. I just cleared cache and re-run the CI process. |
|
Thank you for updating! It looks good to me. |
|
@smaeul Do you have any other (preparing) pull request? If it doesn't, I will release the merged version as the minior updated version. Please let me know. |
Thanks for the quick review! I have opened issues or PRs for everything I have encountered so far. |
alloc::sync::Arcis unavailable on targets without atomics, such as ESP32-C3, which is riscv32imc. In this case, useRcinstead, and make the user responsible for synchronization.I'm not sure if it is okay to do the fallback silently, or if you'd prefer to gate this behind a feature. This is the same condition as used by
alloc, so this change should only affect targets which previously would fail to build.