-
Notifications
You must be signed in to change notification settings - Fork 8.3k
add queued operation manager #23333
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
Closed
Closed
add queued operation manager #23333
Conversation
This file contains hidden or 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
|
All checks are passing now. checkpatch (informational only, not a failure)Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
666a3ce to
bc1090b
Compare
Extracted transition functions from onoff structure to external one which allows to keep them in flash. Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
f3ab85f to
76764a0
Compare
7bc59ec to
df617cc
Compare
k_poll() for a signal is often desired for notification of completion of asynchronous operations, but there are APIs where it may be necessary to invoke "asynchronous" operations from contexts where sleep is disallowed, or before the kernel has been initialized. Extract the general notification solution from the on-off service into a utility that can be used for other APIs. Also move documentation out to a resource management section. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The original API was misnamed, as the intent was to provide a manager that decoupled state management from the service that needed to be turned on or off. Update all the names, shortening them where appropriate removing unncessary internal components like _service. Also remove some API that misled developers into believing that onoff managers are normally expected to be exposed directly to consumers. While this is a use case, in most situations there are service or client-specific actions that need to be coupled to transition events. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Upcoming changes will inform the clients of the state of the system at points where it changes. Make the state-related bits visible to enable the clients to determine the current state. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Upcoming revision of notifications for cancelled operations includes the possibility that a client originally submitted for a request operation will instead receive a notification for a completed release operation. Although this doesn't solve the problem for spinwait or signal notifications, add the state-at-completion as a parameter to the callback notification signature. Since we're changing things, move the user data parameter to the last argument, which is its position in most other callback APIs. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
An original design goal of the onoff infrastructure was to ensure that any errors discovered during transitions would be communicated to at least one client. To meet this goal cancellation of the last client associated with an in-progress transition must be rejected. This ends up significantly complicating the logic associated with operation cancellation, and impacted clients that were forced to maintain state to issue a release or request when the in-progress transition completed. Rework transition management so that both request and release transitions can be accomodated at the same time. Leave a cancelled request notification uncompleted, as the client can tell by the cancellation return value that it has received control of the client object. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
It's possible to have a transition complete with no clients available to receive the result, which may be a notification of error. Alternatively a notification that was originally associated with a release may be converted to a notification associated with a request due the cancellation of the release. There is no way to detect this from spinwait or signal notifications. Also a module may want to centralize tracking of current state and error handling for an onoff service that gets used from multiple contexts. In support of this provide API to monitor state changes within an onoff service. Include notifications when the service transitions out of stable (ON or OFF) states as well as detection of errors. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When functionality that requires an onoff service is affected by external asynchronous actions, such as plugging and unplugging of connections, the management of the current state of an asynchronous service is too complex to handle in individual clients. Provide an intermediary that can handle an arbitrary sequence of interleaved requests and releases, tracking the most recent desired state and notifying the client only when the state has been reached. DNM until API and behavior has stabilized to the point where the depth tracking and PRINTK trace facility can be removed. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Full asynchronous support for APIs such as bus transactions generally require managing operations from unrelated clients. This API provides a data structure and functions to manage those operations generically, leaving the service to provide only the service-specific operation description and implementation. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
df617cc to
63c14ad
Compare
Contributor
Author
|
onoff solution has been completedly redesigned, this branch is not viable. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area: API
Changes to public APIs
area: Documentation
area: Tests
Issues related to a particular existing or missing test
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 PR supersedes #22853, providing a manager abstraction for a prioritized sequence of exclusive transactions on a service. It is based on #23229. Only the top few commits are specific to this PR; please comment on the onoff manager and async notification service changes/additions in #23229.
There is likely little point in spending time reviewing this until at least the initial commits of #23229 have enough approval to warrant a real PR.