Memory pool interface design

[Oleg Goldshmidt]

Elazar Leibovich <elazarl at gmail.com> writes:

> My question is, should I support the case of malloc failure. On one
> hand, it complicates the API significantly, but on the other hand it
> might be useful for some use cases.

This sounds like, can you guys tell me what my requirements are? ;-)

If I understand correctly, you want to provide an alternative (to the
standard malloc() and friends) mechanism for memory allocation,
targeting primarily embedded systems. If I am not completely wrong,
consider the following:

1. Is "mechanism" the operative word? If so, then you should leave
   *policies* - including exception handling - to the client. If you
   intend to restrict your library to a single OOM excepton policy you
   should document the restricton. E.g., if your policy is going to be
   "segfault" or "commit a clean(ish) seppuku", you should tell
   potential users, using big bold red letters, "if this doesn't suit you
   don't use the library."  How much this will affect your library's
   usefulness/popularity I don't care to predict.

2. Naively, I cannot imagine *not* letting clients of a
   production-quality library decide what to do, if only to write
   something sensible to a log using the client's preferred format and
   destination. Some 20 year ago I saw popular (numerical) libraries
   whose authors (probably members of the academia) considered abort a
   legitimate way of handling failures. A scientist running a numerical
   application with the ultimate purpose of writing a paper certainly is
   justified in thinking that way. We, however, disqualified those
   libraries for any production use for that reason alone, regardless of
   their other qualities. IIRC we liked one of them enough to find *all*
   the places where it aborted and modify the code (FOSS rules, huh?).

3. There are enough examples of custom allocators. I am sure you can
   find an awful lot of code, say, overriding new/delete in C++. Even
   the standard libraries provide for overriding allocators. Find a few
   reputable example, see how exceptions are handled, follow the
   pattern? I suspect in most cases it is left to the library clients
   (arguably easier with longjumping exceptions than with C-style error
   propagation, but the point is, library code does not decide,
   usually).

4. What *are* your requirements? If a git client (an example you cited)
   tries to malloc, gets NULL, tries to recover, and then gives up and
   dies writing something to stderr, that's one thing. An embedded
   device just crashing without telling anyone what's wrong? Maybe a
   different kettle of fish altogether. Do you target devices with
   limited or somewhat limited - resources? May make a difference.

5. You mentioned swapping. That does not mean you are out of memory
   (malloc does not fail whan you swap pages). But I am sure you know
   that.

6. Kernel's OOM killer mechanism is also not directly related to
   malloc() failing. It means that *some* process, not necessarily (or
   even likely) the process that is requesting memory at the moment,
   will be killed, according to some policy. No one can decide in
   advance whether killing *something* is a good decision in an
   unspecified embedded system.

7. Why do you say handling failures will complicate the API a lot? It is
   not clear from what you wrote. After all, malloc() is not more
   complex because it can return NULL, is it? So can your alloc() member
   - what's the problem?

-- 
Oleg Goldshmidt | pub at goldshmidt.org