Figure out how QR code parsing can be used safely with the MemoryInit requirement #3398
Comments
|
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
|
@kpschoedel also. #3260 talks about "embedded device-side code", which |
|
This is one reason I don't really like CHIPMem.h — it makes it harder to combine CHIP-library code with non-CHIP code. That being said, my current intent for #3178 (Use mbedtls_platform_set_calloc_free() for non-malloc() configurations), after sleeping on it, is
In this case, the generic MemoryInit() and MemoryShutdown() can easily ensure that they call the implementation functions only once. |
|
Another possible API is to allow arbitrarily many calls to |
|
@kpschoedel That would work for the use cases here, I think. @sagar-apple pointed out that at least for the "show QR code on screen" use case the device does need to use |
Assuming it gets wrapped anyway, the allocator implementations can assume no nested calls, and the specification of MemoryShutdown can be independent of the allocator implementation. |
#### Problem Some code wants to use `CHIPMem.h` allocation in contexts where higher-level code might or might not already have initialized it. Allowing multiple calls (proposed in issue project-chip#3398) solves this. #### Summary of Changes - Rename the allocator-specific `MemoryInit()` and `MemoryShutdown()`. - Call those renamed functions from an allocator-independent `MemoryInit()` and `MemoryShutdown()` that allow mulitple calls and invoke the underlying allocator only once. Fixes project-chip#3398 — Figure out how QR code parsing can be used safely with the MemoryInit requirement
#### Problem Some code wants to use `CHIPMem.h` allocation in contexts where higher-level code might or might not already have initialized it. Allowing multiple calls (proposed in issue project-chip#3398) solves this. #### Summary of Changes - Rename the allocator-specific `MemoryInit()` and `MemoryShutdown()`. - Call those renamed functions from an allocator-independent `MemoryInit()` and `MemoryShutdown()` that allow mulitple calls and invoke the underlying allocator only once. Fixes project-chip#3398 — Figure out how QR code parsing can be used safely with the MemoryInit requirement
#### Problem Some code wants to use `CHIPMem.h` allocation in contexts where higher-level code might or might not already have initialized it. Allowing multiple calls (proposed in issue project-chip#3398) solves this. #### Summary of Changes - Rename the allocator-specific `MemoryInit()` and `MemoryShutdown()`. - Call those renamed functions from an allocator-independent `MemoryInit()` and `MemoryShutdown()` that allow mulitple calls and invoke the underlying allocator only once. Fixes project-chip#3398 — Figure out how QR code parsing can be used safely with the MemoryInit requirement
#### Problem Some code wants to use `CHIPMem.h` allocation in contexts where higher-level code might or might not already have initialized it. Allowing multiple calls (proposed in issue #3398) solves this. #### Summary of Changes - Rename the allocator-specific `MemoryInit()` and `MemoryShutdown()`. - Call those renamed functions from an allocator-independent `MemoryInit()` and `MemoryShutdown()` that allow mulitple calls and invoke the underlying allocator only once. Fixes #3398 — Figure out how QR code parsing can be used safely with the MemoryInit requirement
Problem
QR code parsing was changes to use
Platform::Memorybits, but that requires aMemoryInitcall. Unfortunately, scanning and parsing of a QR code can happen independently of overall CHIP stack bringup. This was mentioned as a possible issue in #3397 (comment) and we ran into this exact issue in the iOS CHIPTool as well.Proposed Solution
Allow multiple calls to
MemoryInit, with the ones after the first call no-ops except for incrementing a counter. HaveMemoryShutdowndecrement the counter; in case it ever becomes nontrivial, the nontrivial actions will be taken only when the counter goes to 0. Once that's done, the QR code parsing bits can init and shutdown around whatever work they need to do.Alternately, we could go back to not using
Platform::Memoryfor QR code parsing, since that's not going to be running on constrained devices....@andy31415 thoughts?
@sagar-apple
The text was updated successfully, but these errors were encountered: