Elazar Leibovich <elaz...@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 | p...@goldshmidt.org _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
