Memory Pools

[ReidP-source]

Memory pools provide deterministic, constant-time allocation from pre-reserved static memory, avoiding heap fragmentation and unpredictable allocation failures associated with malloc on constrained devices. In Loom, the pool can replace any dynamic and static buffer allocations with a single source memory manager making controlling memory easy and more reliable.

Not complete
The pool allocator will apply backpressure by refusing allocations it cannot satisfy (e.g., returning nullptr / signaling NEED_DRAIN). The caller can drain pending transmissions or switch to streaming behavior. Bounds safety will be enforced by the read API: callers will receive both the buffer capacity and the number of bytes written, and SD reads will clamp to the allocated capacity to prevent overflow.

e.x usage:

MemPool ChunkPool; // MemPool Object

size_t chunkBytes = 2000 // 2KB chunk

struct ChunkState {
    MemPool::Handle handle;
    size_t capacity;
    size_t used;
    bool writeOk;
};

...

// Make a handle and validate it again (not strictly necessary but BP)
// MemPool allocates in blocks of 64 bytes. You will always receive a large enough buffer but it can be larger.
 MemPool::Handle h = ChunkPool.alloc(chunkBytes + 1);  // Allocates a buffer for atleast 2001 bytes (leaves space for '\0')
    if (!sensorChunkPool.valid(h)) {
        ERROR(F("sensorChunkPool alloc failed"));
        return false;
    }

// Put the handle into a app-level state tracker 
ChunkState state = {h, chunkBytes, 0, true};