-
Notifications
You must be signed in to change notification settings - Fork 109
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
Document plans on async
/Futures
#425
Comments
I would like to have At a high level: There is more background on this decision at #334 and the issues and PRs it links to. I tried to implement a more capable form of asynchrony, but found that there were a lot of nontrivial design decisions to make, and without any use case for that asynchrony, I didn't have the information needed to produce a quality implementation. If you have a use case that |
Thank you for linking to #334! While I’m still struggling to understand the exact nature of the issues you faced there, I can at least appreciate the general sentiment of wanting to be presented with a more solid use-case before committing a bunch of work to this. Thinking about this a bit more, I’ve realized that my current use-case (single-app, waiting on 2-4 event sources and advancing state based on these) would in fact not greatly benefit from Futures support. Once TockOS gains a network stack (cf tock/tock#3103 comments), I’d like to augment this app with another one offering the services of this initial app, as well as a bunch of sensor readings over TCP (probably using the MySensors Serial Protocol). That might then be closer to the kind of use-case you are looking for, we’ll see. |
Looking through closed issues and previous and current code, this library used to offer
async
/await
functionality in the past (Tock 1.x), but it got culled during the 2.0 work. While #160 (comment) ff mentions problems with added code size on low-memory boards, the consensus appeared to be that there should be a Futures-free/callback-based API alternative. However the current state is a synchronous-only API.Is it planned to bring back
async
support at some point in the future (similar to the now-missing memory allocator: #397) or was this a permanent change?The text was updated successfully, but these errors were encountered: