-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[chip-tool] Add delay commands module to chip-tool with busy-wait com… #24063
[chip-tool] Add delay commands module to chip-tool with busy-wait com… #24063
Conversation
PR #24063: Size comparison from 64b2ca4 to 1fdc183 Increases (7 builds for bl602, linux, nrfconnect, qpg, telink)
Decreases (7 builds for bl602, bl702, esp32, psoc6, telink)
Full report (35 builds for bl602, bl702, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
@vivien-apple please add more details to the summary: why is this needed. The "hint" text does not seem to help me understand ... why is a busy loop better for interactive work? |
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.
The PR summary describes what is done (add a busy wait loop) but not why.
Please exaplain why a bit clearer. My instinct is to complain on any busy loop in our code - using 100% CPU to wait for a time seems wrong. It needs very strong justification in case this is the only thing possible.
1fdc183
to
7e330c5
Compare
7e330c5
to
7ff9db3
Compare
PR #24063: Size comparison from 8055d86 to 7ff9db3 Increases (9 builds for bl602, bl702, cc13x2_26x2, cyw30739, esp32, linux, psoc6, telink)
Decreases (5 builds for bl602, bl702, cc13x2_26x2, telink)
Full report (42 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
Busy loop replaced with sleep. Still needs some comment and PR description updates.
@andy31415 I have updated the PR summary. |
7ff9db3
to
f6468fe
Compare
PR #24063: Size comparison from b49c3ed to f6468fe Increases above 0.2%:
Increases (11 builds for bl602, bl702, cc13x2_26x2, esp32, linux, psoc6, telink)
Decreases (7 builds for bl602, cc13x2_26x2, esp32, psoc6, telink)
Full report (53 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
PR #24063: Size comparison from 0f3039f to 6ba19f1 Increases above 0.2%:
Increases (6 builds for bl702, linux, nrfconnect, psoc6, telink)
Decreases (7 builds for bl602, esp32, k32w, psoc6, telink)
Full report (53 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
…mand (project-chip#24063) Co-authored-by: Andrei Litvin <[email protected]>
…mand
Problem
[hint] This is different than #23886 in the sense that it can be used at any time during an interactive session.
That makes it useful to try to not asked messages from the server, such as the messages from a subscription.
One of the thing this PR tries to achieved is to trigger an
INVALID_SUBSCRIPTION
status response when a subscription is in place. The mechanism used is to prevent any message processing from the stack for a duration longer than the subscription maximum interval + the mrp retries.As an example:
The messages are queued during this interval (and not dropped) and so they are delivered to the message processing code afterwards. Which in turn trigger the stack to ack the reports but the subscription is closed on the other side.