talloc_tos() in common code

[tridge at samba.org]

Hi Volker,

 > That's not different from the current situation, except that
 > with more proper use of talloc_stackframe in public
 > functions the inner functions are safer from generating
 > memleaks if due to a bug a temporary talloc context is not
 > freed. Just see talloc_stackframe() as the normal way to
 > allocate temporary talloc contexts. With every proper use of
 > talloc_free(frame) at the exit of a function you gain a
 > little bit of safety for the functions called from there.

ok, that could work, although I expect we will end up sometimes
causing memory leaks in external code, if we aren't careful enough in
cleaning up. We may not notice it easily as our own code would have
cleanup calls.

One approach would be to not put the cleanup stuff in the main s4
code. So when s4 calls common code, it will get a leak if the common
code doesn't cleanup properly. Or have the cleanup there, but print a
message if it ever has to actually free something.

If we don't adopt some strategy like this then we will be forever
chasing down memleaks in our public libraries, as developers could
quickly become complacent about cleanup, relying on it being done
somewhere else.

One of the things I've always preferred about talloc over traditional
garbage collection systems is that the programmer has greater control
over when memory is released, so you don't get big delays when garbage
collection kicks in. I'd prefer we didn't end up with that property by
adopting "global pools" too much. This is especially important as
talloc is very inefficient at hierarchies with lots of pointers
handing directly off a single pointer (due to how it deals with the
lists). It deals much better with "bushier" hierarchies.

Cheers, Tridge