Document plans on `async`/Futures
ntninja opened this issue · comments
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?
I would like to have Future support, but I do not see a way to build it on top of the current libtock-rs API. Therefore, I do not have any plans to re-introduce a Futures-based API.
At a high level: libtock-rs currently exposes an asynchronous API, not a purely synchronous one. However, the API is only designed to support what I call "local asynchrony": you can run multiple operations asynchronously within a single function, but it does not support pausing and resuming the execution of a function.
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 libtock-rs' current APIs don't support, then please share some details, and we'll try to support you.
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.