On a continuation to discussion on the issue #41 of malloc_info() altering heap state, given we remove the call of _Heap_Protection_free_all_delayed_blocks() from being called through malloc_info(), does any other specific trigger point exist for the cleanup like there exists in some allocators like mimalloc?
I came across this article of mimalloc and figured out that there is specific trigger point for maintenance(Section 2.3) of delayed blocks i.e. their per-page local free list getting empty which consists of blocks available for immediate use. Every time a page’s local free list gets empty, mimalloc enters a slow path in which their recently used list of blocks for that page gets into page local free list and the main deferred free list also gets processed via a generic routine.
Are there any similar or equivalent trigger points in RTEMS which triggers a routine calling _Heap_Protection_free_all_delayed_blocks()? And should we introduce one ?
From my observations, these are only places _Heap_Protection_free_all_delayed_blocks() is being called to process delayed blocks.
./cpukit/rtems/src/regiondelete.c: _Heap_Protection_free_all_delayed_blocks( &the_region->Memory );
./cpukit/score/src/heapresizeblock.c: _Heap_Protection_free_all_delayed_blocks( heap );
./cpukit/score/src/heapgreedy.c: _Heap_Protection_free_all_delayed_blocks( heap );
None of them appear like to be inside a function which could be a possible definite point which causes processing of delayed blocks?