WIP: no_std support for async macro #935
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All changes in the first commit should be good to go.
The second commit has a SUPER UNSAFE implementation of context passing. It works in my specific use case because I promise to never touch futures in interrupt handlers and run on a single-threaded microcontroller, but definitely needs to be implemented differently to ensure users can't accidently pass the wrong context to different futures.
I have had a brief look at how
futures
0.1 handled supporting basically a user overridable thread local implementation, putting the onus of safety on the user that calledfutures::task::init
. I would really love to avoid having to reintroduce that API (especially having to fully understand that implementation, there appeared to be a lot of implementation details concerned with ensuring any cost introduced by it is optimized out onstd
builds), so any hints on potential alternatives would be greatly appreciated.If no-one has any potential alternatives, I'll take a better look at the old
futures::task::init
sometime this/next week and see how horrible supporting it will be.