Re: out-of-memory handling

[Bruno Haible]

Marc Nieper-Wißkirchen wrote:
> >   2) We have a dilemma regarding use of malloc vs. xmalloc. While modules
> >      meant for use in programs can readily use xmalloc, modules meant for 
> > use
> >      (also) in libraries cannot use xmalloc, since a library is not supposed
> >      to terminate the program, even when memory is tight.
> 
> GMP more or less has this behavior.

Indeed, GMP's out-of-memory options [1] are poor in this respect:
  "There’s currently no defined way for the allocation functions to recover
   from an error such as out of memory, they must terminate program execution.
   A longjmp or throwing a C++ exception will have undefined results."
Likewise for libffcall, alas.

> >      The solution we found for this dilemma is that the *-set and *-map 
> > modules
> >      use just malloc, and we have thin wrapper modules (xset, xmap) that do
> >      call xalloc_die() in case of out-of-memory.
> >
> >      Unfortunately, the API of many of the functions need to be adjusted to
> >      cope with the possibility of an ENOMEM failure. That is tedious work, 
> > and
> >      the code does not look so pretty afterwards... But I see no other way 
> > to
> >      make it fit for use in libraries.
> 
> The bigger problem is that it mustn't make the code slower for the
> 99,99999% of the use cases where there is either enough memory or
> calling xalloc_die is the only reasonable action.

OK. When we add hamt as a possible implementation for gl_set and gl_map, we
could document that out-of-memory handling must be done
  - either through xalloc_die(),
  - or by defining xmalloc and xrealloc [this is what Emacs does],
unlike for the other implementations.

Bruno

[1] https://gmplib.org/manual/Custom-Allocation