bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HAMT for gl_set and gl_map


From: Bruno Haible
Subject: Re: HAMT for gl_set and gl_map
Date: Sun, 11 Oct 2020 16:01:02 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; )

Hi Marc,

> > How would a HAMT implementation look like that does not support persistence,
> > but is instead optimized for destructive updates? Probably the reference
> > counters would go away. Anything else?
> 
> The reference counter would go away as would all tests for "shared" in the 
> code.
> 
> Without a reference counter, an element can be any "void *" (instead
> of a pointer to a struct starting with Hamt_entry), which is a
> substantial change.

Thanks for explaining.

> We can add a number of #if's to the code so that it either compiles to
> an implementation of persistent or of transient hamts, but I wouldn't
> rather do it right now because it would make the code harder to read.
> But when the hamt code has become stable (and has been put to use and,
> therefore, to real-world testing), this sounds like a feasible option.

I agree that stabilizing the current code should come first.

Then, whether the adaptations will be doable with a small set of #ifs
or whether it will be best to copy the code, will remain to be seen.
I mean, there are different red-black tree implementations in Gnulib
and in the Linux kernel, and it does not cause maintenance problems
because algorithmic code only very rarely needs updates.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]