M Hightower

> Right now, only ~umm_info()~ getHeapStats() implementations is accepting ctx pointer, ... Ahh, that's where those went. Those did not show up on my search, because the current changes I...

> void deallocate(void* ptr) { umm_free_core(_ctx, ptr); } For `free`, it may be easier and safer to just let it select the Heap free context; however, providing the context in...

> ... providing the context in the call would speed things up. This would become a problem with free-ing an allocation that was made from ISR and was forced to...

> True, but... it can also just fail for everything that isn't dram ctx ... I think part of the concern here was a class being instantiated from within an...

I am not sure I follow your line of thinking. Because of the potential of Heap allocating/freeing during an IRQ, INTLEVEL is raised to protect against changes while accessing Heap...

Sorry, I am still having trouble following. For most of the data in _context, it is all read safe. When updating, global locks are usually in place because we are...

The approach has been tested; however, this PR with the approach has not been verified. Otherwise, it is ready. Also for umm_init, do you agree with the change back to...

> On a Wemos D1 mini board (really old one, so might be one of those "true" Wemos boards) it runs quite OK. But on a Sonoff POW r2 it...

> Or only intended for those who need more ISR code for interrupt handling stuff etc? Yes, `16k cache and 48k iRAM` is to provide larger code space for iRAM-hungry...

> Shouldn't those 32-bit aligned pointers be marked as volatile ? I don't see the need unless you use it from an ISR. All references/accesses are in plan view to...