Memory pool interface design

[Oleg Goldshmidt]

Elazar Leibovich <elazarl at gmail.com> writes:

> Regarding 5-6. What I'm saying is, seeing malloc returning NULL in
> production is very rare. 

Hope dies last.. ;-)

> I personally never seen that. 

So you've been lucky so far. At some point you will inevitably run into
client code that occasionally does something stupid like passing a
signed integer as size. Trust me, when that happens the size parameter
usually turns out to be -6. You will have no control over it.
  
> I think that the OOM killer would wreck havoc to the system before it
> would happen,

Why do you assume that? How *can* you assume that given that OOM
policies can be configured (at runtime)?

Apart from everything else, why do you assume that malloc only fails
when there is not enough memory? 

And if you allow - nay, require! - that the user specifies a custom
allocator, how do you know *that* won't fail for some weird (or
perfectly logical, as the case may be) reason?

> hence, crashing when malloc returns NULL is a reasonable behavior.

For a non-critical single process application under very special
circumstances - maybe. What if the crash happens while client code is
tweaking some shared memory, holding a lock or some other resource
(where a crash would leave some data your library does not control in an
inconsistent state that will cause problems for other processes or after
restart), or in general needs to do some cleanup / bookkeeping / logging
(to tell the user what happened) before dying - how can you possibly
call hard crash "reasonable behaviour"?

> Regarding 7, this does not complicate the allocation API, it
> complicates my API, since I'll have functions that cannot fail,
> generally speaking, but allocates memory.

This implies that you need to handle allocation (and all other) errors
inside such functions to provide the "no exceptions" guarantee. Your
options, in order of increased sophistication (you can actually do this
in stages and hope to get feedback rather than being ignored):

1. Decide how and do that - that's a policy. See if this is attractve to
   your users. Hope to get emails saying "I wish you didn't abort."

   [If you get such emails feel very proud - someone cares enough, you
   probably did a very good job on everything else.]

2. Provide several different policies and a configuration mechanism to
   choose - see if this is more successful than #1 above. Hope to get
   emails saying "I wish you would add this other policy."

3. Provide a callback hook so that a user can implement and register a
   handler - effectively, support custom policies.

   By the time you get to this stage you may realize that you may just
   as well return a status code and let the user handle the
   condition. I expect this to be easier for users than registering
   callbacks. It will also be more flexible since different policies may
   be applied in different places in a single client program.

> Those would have to return error, and the user would have to check the
> error.

As both Guy and I said before, this is the proper behaviour for a
general purpose library.

-- 
Oleg Goldshmidt | pub at goldshmidt.org