Talloc and Tdb spin offs

[tridge at samba.org]

Simo,

 > I am not sure this can be done in a useful way if you mean doing
 > something like #define malloc my_talloc_malloc(...).

no, I don't mean that. I mean a full replacement malloc library.

 > The only case where that would work, I guess, is when you recompile an
 > application from scratch with all libraries, or, if you can intercept
 > glibc's malloc/free through some kind of LD_PRELOAD trick. Otherwise any
 > time you link to a library at runtime things will just break. I just
 > experienced a bug like this with some code in bind.

We shouldn't need LD_PRELOAD tricks. libtalloc would include the
symbols for malloc, free etc, and those would be found by the loader
and used by all code (including linked libraries).

 > I am reading this code and it seem interesting, but one thing that seem
 > a no-go, imo, is the "compile time" thread safety. If you use this code
 > in a library you want to be thread safe, but possibly only when
 > necessary. If it is a compile time option that means a
 > developer/packager will have to always compile in the thread safety
 > functions, just in case

if you are using this as a general system shaed lib you'd always have
to compile in the thread safety code. That slows it down (though not
by a lot).

 > Is there any other advantage?

yes, it uses vastly less memory with some allocation patterns than
glibc malloc. For example, it saved us more than 80% of memory when
used with current Samba4 instead of system malloc.

The main aim of alloc_mmap is to make for very compact memory usage,
and always releasing memory back to the system if possible. It also
happens to form a good basis for a system allocator for talloc

 > Have you considered systems with huge pages ?

this allocator doesn't want them

Cheers, Tridge