Re: out-of-memory handling

2020-10-11 Thread Marc Nieper-Wißkirchen
Am So., 11. Okt. 2020 um 13:56 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > I am not so convinced of whether it makes sense to create a > > gl_set/gl_map frontend for this hamt implementation. > > Wikipedia [1] lists some advantages of HAMTs even without the persistence. > > > I

Re: out-of-memory handling

2020-10-11 Thread Bruno Haible
Marc Nieper-Wißkirchen wrote: > I am not so convinced of whether it makes sense to create a > gl_set/gl_map frontend for this hamt implementation. Wikipedia [1] lists some advantages of HAMTs even without the persistence. > It is optimized > for the persistence (otherwise, use ordinary hash table

Re: out-of-memory handling

2020-10-11 Thread Marc Nieper-Wißkirchen
Am So., 11. Okt. 2020 um 12:54 Uhr schrieb Bruno Haible : > > The bigger problem is that it mustn't make the code slower for the > > 99,9% 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 implem

Re: out-of-memory handling

2020-10-11 Thread 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 t