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
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
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
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