-
Notifications
You must be signed in to change notification settings - Fork 7
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
✨ (eventqueue): Add cancelLastCall #1252
✨ (eventqueue): Add cancelLastCall #1252
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1252 +/- ##
===========================================
- Coverage 96.21% 96.19% -0.02%
===========================================
Files 146 146
Lines 3617 3601 -16
===========================================
- Hits 3480 3464 -16
Misses 137 137
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
File comparision analysis report🔖 Info
Click to show memory sections
📝 SummaryClick to show summary
🗺️ Map files diff outputClick to show diff list
|
File comparision analysis report🔖 Info
Click to show memory sections
📝 SummaryClick to show summary
🗺️ Map files diff outputClick to show diff listNo differenes where found in map files. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but after reviewing mbed's documentation, I'm afraid that with the current implementation we might introduce bugs
} | ||
|
||
void cancelLastCall() { _event_queue.cancel(_event_id); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would just use cancel
void cancelLastCall() { _event_queue.cancel(_event_id); } | |
void cancel() { _event_queue.cancel(_event_id); } |
in the future we could have call
return the id
to be able to cancel(id)
and share an event queue between different callbacks
what happens if we call call_every
multiple times? will the queue call all the callback at the desired interval?
if so, then we should first cancel
before using _event_queue.call
or _event_queue.call_every
_event_id
can be an optional to handle the case where cancel is called before call_every
has been called.
@@ -18,19 +18,23 @@ class CoreEventQueue : public interface::EventQueue | |||
|
|||
void dispatch_forever() final; | |||
|
|||
void call(auto f, auto... params) { _event_queue.call(f, params...); } | |||
void call(auto f, auto... params) { _event_id = _event_queue.call(f, params...); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here, the _event_id
is not really needed and could even introduce bugs.
_event_queue.call
will dispatch the event as soon as it's called .
per mbed documentation, when the event is dispatched, the id is not valid anymore and
It is not safe to call cancel after an event has already been dispatched.
id must be valid i.e. event must have not finished executing.
so calling call
and then cancel
might break the program.
cancel is only really needed for call_every
or call_in
7df2d93
to
4c255da
Compare
4c255da
to
f32cafb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Kudos, SonarCloud Quality Gate passed! |
No description provided.