-
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
Change how the Matter framework handles Platform::Memory. #19273
Change how the Matter framework handles Platform::Memory. #19273
Conversation
Since for the malloc case the Platform::Memory is just debugging bits, and since its init is not particularly threadsafe, just do a dispatch_once init whenever we might need it, and don't worry about shutting it down.
PR #19273: Size comparison from 8cc291d to 8a2182b Increases (1 build for telink)
Decreases (1 build for nrfconnect)
Full report (41 builds for cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, p6, telink)
|
Don't both The PR looks fine, but wanted to ensure my understanding of expectations there were correct. |
That's ... extremely unclear. They also have atomic refcounting, which makes no sense with external synchronization. See also #18675
Yes, and I considered doing just that (a special dispatch queue with |
…ip#19273) Since for the malloc case the Platform::Memory is just debugging bits, and since its init is not particularly threadsafe, just do a dispatch_once init whenever we might need it, and don't worry about shutting it down.
Since for the malloc case the Platform::Memory is just debugging bits,
and since its init is not particularly threadsafe, just do a
dispatch_once init whenever we might need it, and don't worry about
shutting it down.
Problem
See above.
Change overview
See above.
Testing
Ran Darwin framework tests.