Memory pool interface design

[Elazar Leibovich]

I'm writing a small C library, that I want to open source.

I want them to be usable for embedded environment, where memory allocation
must be controlled.

Hence, I abstracted away calls to malloc/realloc, and replaced them with

struct mem_pool {
    void *(*allloc)(void *mem_pool, void *prev_ptr, int size);
};

User would implement

struct my_mem_pool {
    struct mem_pool pool;
    ...
};

struct my_mem_pool pool = { { my_alloc_func }, ...);

I've had to design question I'm interested with:

1) Should I support both malloc and realloc?

I think the performance benefits of supporting malloc instead of
realloc(NULL) are negligible, and not worth complicating the interface.

2) Should the memory pool be allowed to fail?

In typical Linux system, where memory overcommit is allowed, checking
malloc return value provides little benefit. But is it the same for
embedded system?

My feeling is, embedded system should predict the memory usage for each
input size, and avoid processing input which is too large.

For example, stack overflow error can never be handled, and one is expected
to calculate the longest stack length for any input and make sure he
wouldn't overflow.

So I think it's still reasonable never to report allocation failure, and to
expect the memory allocator to raise the relevant abort/panic/exception in
such a case.

But I'll be happy to hear other considerations I missed.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150515/4b9a8cdb/attachment.html>