Skip to content
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

Open
ntninja opened this issue Jul 30, 2022 · 2 comments
Open

Document plans on async/Futures #425

ntninja opened this issue Jul 30, 2022 · 2 comments

Comments

@ntninja
Copy link

ntninja commented Jul 30, 2022

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?

@jrvanwhy
Copy link
Collaborator

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.

@ntninja
Copy link
Author

ntninja commented Jul 31, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants