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

Make interface non-blocking #57

Merged
merged 7 commits into from Jan 4, 2021
Merged

Make interface non-blocking #57

merged 7 commits into from Jan 4, 2021

Conversation

hannobraun
Copy link
Owner

@hannobraun hannobraun commented Dec 17, 2020

Currently blocked on #54 and #56. Requires a rebase once those are merged.

As the title says, this PR makes the interface non-blocking (more explanation in the commit messages). Also contains some clean-ups that can stand on their own. I plan to break those out into separate pull requests for easier review, once the pull requests this is blocked on are merged.

This adds quite a bit of complexity, but I think it's worth it (or rather, non-optional). A lot of this can get cleaned up significantly once we can use async/await, but that requires more support in the embedded ecosystem. There's some movement there, from what I hear, but all of it is a bit too tenuous to block this pull request, in my opinion.

List of things to do after merging this:

Close #5

The convenience of the current API is preserved with the
`StepFuture::wait` function. Otherwise, this commit introduces a
significant amount of complexity.

I think that's worth it, given the new capability. Especially as I don't
know how to do any better right now, and since this is bound to get
_much_ better (both for the user and in the implementation), once the
embedded ecosystem grows sufficient support for async/await.
@hannobraun hannobraun marked this pull request as ready for review January 4, 2021 16:19
This might not be necessary right now, but as more futures and state
enums are added for other operations, the `driver` module is bound to
become overloaded.
This doesn't seem like much of a restriction, given what `StepMode` is,
and all the generated types derive it. This is going to make some custom
future code more straight-forward to implement.
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

Successfully merging this pull request may close these issues.

Add non-blocking API
1 participant