Support building in no_std environments
#69
Conversation
| thread_local!(static CTX: Cell<StaticContext> = Cell::new(ptr::null_mut())); | ||
|
|
||
| #[cfg(not(feature = "std"))] |
There was a problem hiding this comment.
Can you explain this impl here? It seems totally unsafe to me-- no_std systems can still have threads, so accesses to CTX would be unsound, right?
There was a problem hiding this comment.
Yeah, I was kinda hoping someone else might have some idea how to make this safe on threaded no_std. The best solution I see is using generator arguments to avoid CTX entirely with and without no_std, but I don’t know what the current status on those are.
I guess there’s the old design of futures 0.1 where you have to call an init routine to setup the thread locals on no_std, pushing the safety requirements onto the user of the library.
There was a problem hiding this comment.
After glancing at the futures 0.1 task::init setup, I really don't want to have to fully understand that to make sure it's safe here. It's also really not how we would want to have the library work in the end since futures-await should be a private library able to be used by dependencies without the application needing to know about it.
Still missing a solution to passing context in without thread local support.
|
Moved to rust-lang/futures-rs#935 |
This doesn't actually build on targets that don't provide a
stdcrate because of some missing changes infutures 0.2.0-alpha, but it does successfully build ano_stdversion of thefutures-awaitcrate on targets that provide astdcrate.This branch + rust-lang/futures-rs#845 + a custom executor is capable of running self-referential
#[async]futures on alloc-less bare-metal devices 🎉I'm really not sure what to do about the context storage, as far as I'm aware this is safe on single-threaded devices, but I'm not sure if this might ever be used on a non-single-threaded device.