-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
k_delayed_work_cancel documentation inconsistent with behavior #22803
Comments
Thanks. For my use-case I think a function similar to k_work_pending for k_delayed_work would have been very useful. Between the timeout running out (k_delayed_work_remaining_get) and the timeout handler submitting (or not processed) it's no possible to check if the delayed work has been submitted, but not completed. |
So I was with the right impression on this one and the documentation is wrong in one way or the other, the question is shall we change the implementation to reflect what is stated in the documentation? That would mean cancel would return an error if neither the timer or pending flag is set. Something like this:
|
This is aligned with the documentation which states that an error shall be returned if the work has been completed: '-EINVAL Work item is being processed or has completed its work.' Though in order to be able to resubmit from the handler itself it needs to be able to distinct when the work is already completed so instead of -EINVAL it return -EALREADY when the work is considered to be completed. Fixes zephyrproject-rtos#22803 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This is aligned with the documentation which states that an error shall be returned if the work has been completed: '-EINVAL Work item is being processed or has completed its work.' Though in order to be able to resubmit from the handler itself it needs to be able to distinct when the work is already completed so instead of -EINVAL it return -EALREADY when the work is considered to be completed. Fixes #22803 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
zephyr/include/kernel.h
Line 3117 in c6d37eb
k_delayed_work_cancel()
. Specifically, if the work item has already completed the function will return zero, rather than-EINVAL
. Assuming the states of a work item:the only time
-EINVAL
would be observed is in never-submitted, cancelled, or if it transitioned from pending to processing during the cancellation attempt.The intent may have been to implement to the documentation; in that case the
work_q
value must be set to null after processing (which may be risky), and possibly other conditions need to be reviewed.This had an impact in #22756 where it is not possible to determine whether a pending operation has been completed without maintaining an external flag.
The text was updated successfully, but these errors were encountered: