rust-lang
Support for no_std targets without atomics extension
Hello,
First of all, thank you for your work on futures.
I'm working on a project targeting various ESP32 microcontrollers using esp-hal, a few of them e.g., esp32c3, do not have support for atomics and therefore no access to core::sync::atomic and alloc::sync::{Arc, Weak}.
The idea is to evaluate what needs to be done to support most if not all sub-crates of futures on such platforms. This is commonly achievable using the portable-atomic and portable-atomic-util crates which is what futures_core offers behind the portable-atomic feature.
I'd like your insights on offering a common Arc implementation that can be used over all of futures' sub-crates, mainly futures-task/src/waker.rs and futures-task/src/arc_wake.rs.
Something to keep in mind,portable-atomic-util extends portable-atomic with alloc-related functionalities which could theoretically be feature-gated by alloc itself. However, I am not sure if cargo's features system would allow us to selectively enable either alloc by itself or alloc and portable-atomic-util dependency if both alloc and portable-atomic are enabled.
This issue might also require a nightly compiler mainly to enable #![feature(arbitrary_self_types)].
In attempt to implement this, I realized that tests can be hard to follow as futures is used as a dev dependency instead of the individual sub-crates, but this is not a blocking issue.
Related work
- https://github.com/rustls/rustls/pull/2285 (Ref https://github.com/rustls/rustls/issues/2068).
There are many APIs in futures, so I think it is better to work with a narrower scope based on where you specifically need it.
- It should be easy, except for the public APIs that use Arc and code depend on them.
- As for ArcWake, it is difficult in itself as said below, but it should be possible to use portable-atomic-util's Wake conditionally in the areas where ArcWake is used.
- Using portable-atomic-util types in the public API would not be an acceptable option for futures because it is pre-1.x (unlike portable-atomic).
