Start of Zephyr work-q support #45
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
An earlier change updated all of the crate version numbers to match a Zephyr release. This is problematic for several reasons: - Zephyr releases don't correlate with semantic versions. In general, it is probably best to assume every Zephyr release is a semantic change, and should have a major version bump. - Cargo does make some assumptions about the meaning of semantic versions (for example, that it can use a version that would be considered semantically equivalent. - The Rust support consists of multiple crates, and there is no particular reason to tie the version numbers of those together. At this point, the Rust support for Zephyr is experimental, and definitely needs a 0.x.y version number. Revert everything back to 0.1.0. As this stabilizes more, we can start to come up with appropriate numbers. Although we are quite a w ways from it making sense to include any of this in the crate ecosystem, it will still be helpful to have meaningful numbers if we ever do decide to do that. Signed-off-by: David Brown <[email protected]>
The work module provides various interfaces for interacting with Zephyr work queues. This is a beginning of that support. Signed-off-by: David Brown <[email protected]>
After rebasing on the Zephyr change that moves versions back to 0.1.0, adjust those in the crate we are adding. Signed-off-by: David Brown <[email protected]>
This shouldn't have been checked in. Signed-off-by: David Brown <[email protected]>
Make a real Waker that is in an Ark. There is still some unpleasant casting to get this back to the type, and I haven't done any analysis to see if data is being leaked, but this does not run correctly. Signed-off-by: David Brown <[email protected]>
Adjust for the new futures version, where there is a builder that then has a `start` that returns a `Work` that only holds on to the allocation, and waits for an answer. Signed-off-by: David Brown <[email protected]>
Change the name of the sample to be unique. Signed-off-by: David Brown <[email protected]>
This will catch instances of the work itself being stopped before the Future running in it has terminated. Not ideal, as it should be permissible to drop it. Signed-off-by: David Brown <[email protected]>
The WorkWaker now really does implement Sync, as we use an Arc and Mutex to protect it. Signed-off-by: David Brown <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is some basic playing with Zephyr work queues, eventually with a goal of supporting both direct use of work queues as well as Futures.
This basic version is able to run a simple async Future that can use a 'sleep' function.