Memory pool interface design

[Elazar Leibovich]

What are other practical use cases where malloc returns NULL.

You mentioned programmer error.
I second, and mention restricted environment where admin ulimits your
virtual memory.

I'll be happy to hear more.

On Sun, May 17, 2015 at 9:51 PM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150518/699a09a0/attachment.html>