-
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
[Darwin] Unstored attributes should be flushed to storage on shutdown #36791
base: master
Are you sure you want to change the base?
Conversation
82e5795
to
07cfafb
Compare
PR #36791: Size comparison from 918320e to 07cfafb Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
src/darwin/Framework/CHIPTests/TestHelpers/MTRTestPerControllerStorage.h
Show resolved
Hide resolved
PR #36791: Size comparison from 918320e to d7a85ca Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #36791: Size comparison from 918320e to cf88dab Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Co-authored-by: Boris Zbarsky <[email protected]>
PR #36791: Size comparison from 918320e to 2306949 Full report (69 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
PR #36791: Size comparison from 918320e to e1e64c1 Full report (25 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, nrfconnect, qpg, stm32, telink, tizen)
|
@@ -449,6 +449,13 @@ - (void)cleanupAfterStartup | |||
for (MTRDevice * device in devices) { | |||
[device invalidate]; | |||
} | |||
|
|||
// Since MTRDevice invalidate may issue asynchronous writes to storage, perform a | |||
// block synchronously on the storage delegate queue to flush those operations. |
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.
This comment still doesn't explain why we need to block here on that. To repeat my review comment, which was marked resolved without resolving:
What happens if we don't do that? Won't the writes happen anyway? Or are we worried about our caller tearing down the storage backend if we return from here, before the writes have a chance to happen? Would be good to document why this needs to be a sync point.
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.
Ah I didn't see it before the previous comment was resolved. And yes you were right in that I was worried about storage backend going away after shutdown returns. Let me clarify a bit more.
PR #36791: Size comparison from 918320e to 1fbd14b Full report (54 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
When MTRDeviceController shuts down, if an MTRDevice object still has attributes that have yet to be persisted, the persistent attribute cache may become out of date. And on next startup, subscriptions can cause more priming reports than is necessary.
This PR makes MTRDevice persist unstored attributes on invalidate, and have MTRDeviceController wait for the storage delegate has executed the write blocks before continuing with the shutdown.