-
Notifications
You must be signed in to change notification settings - Fork 2k
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
iOS tv-casting-app: Apply StackLocks and sequence callbacks #26817
iOS tv-casting-app: Apply StackLocks and sequence callbacks #26817
Conversation
* Lock the SDK before interacting with it. [Problem] The Matter SDK assumes that the client will take a lock on the SDK prior to interacting with any APIs. There is 1 Android function and several iOS functions that do not take the lock prior to interacting with the SDK APIs. There are also some functions that invoke the Matter SDK in a way that may result in out-of-order callback invocation (e.g. the conceptual "started" callback may be invoked after the conceptual "ended" callback). [Solution] Create utility functions that help ensure that the Matter SDK is invoked safely and that callbacks are delivered in the correct order. [Testing] Performed local, manual testing with the 'tv-casting-app' example on iOS against a Raspberry Pi running the 'tv-app'. Ran the certification test in the 'tv-casting-app' on iOS against the same Raspberry Pi. * * Updating naming and parameter order for new CastingServerBridge APIs * Refactored the Certification Tests to more fully exercise threading behavior * * Updating the documentation for modified APIs
PR #26817: Size comparison from 6ce2412 to 9084a12 Increases (10 builds for bl602, bl702, efr32, psoc6, telink)
Decreases (11 builds for bl702, cyw30739, efr32, esp32, psoc6, telink)
Full report (58 builds for bl602, bl702, cc32xx, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
// | ||
// Note that it is presently safe to do at this point because InitChipStack is called in the | ||
// constructor for the CastingServerBridge. | ||
chip::DeviceLayer::StackLock lock; |
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.
StackLock is a no-op on the Darwin platform, no? @sharadb-amazon
// | ||
// Note that it is presently safe to do at this point because InitChipStack is called in the | ||
// constructor for the CastingServerBridge. | ||
chip::DeviceLayer::StackLock lock; |
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.
If StackLock were not a no-op on Darwin, this would deadlock, since you are already on the Matter queue and hence holding the lock if there were one.
Fixes #26816
Problem
The Matter SDK assumes that the client will take a lock on the SDK prior to interacting with any APIs. There is 1 Android function and several iOS functions that do not take the lock prior to interacting with the SDK APIs.
There are also some functions that invoke the Matter SDK in a way that may result in out-of-order callback invocation (e.g. the conceptual "started" callback may be invoked after the conceptual "ended" callback).
Solution
Create utility functions that help ensure that the Matter SDK is invoked safely and that callbacks are delivered in the correct order.
Testing
Performed local, manual testing with the 'tv-casting-app' example on iOS against a Raspberry Pi running the 'tv-app'. Ran the certification test in the 'tv-casting-app' on iOS against the same Raspberry Pi.
Refactored the Certification Tests to more fully exercise threading behavior