talloc issues

[tridge at samba.org]

Hi Simo, Sam and Metze,

I've been looking over the talloc discussions to try to come to some
conclusions.

First off, I'd like to apologise to Simo for my choice of words in
some of my messages. Some of my language was inappropriate for a
technical discussion.

Regarding Sam's patches, I still have some of the same concerns that I
posted last time. I think that Sam's changes make the situation
unambiguous only in the same sense that the old talloc code was
unambiguous. The old talloc behaviour was completely deterministic
from a strictly algorithmic sense, in that a talloc_free() on a
pointer with references would remove the most recent reference
first. Sam's patches are similarly unambiguous, in that it removes the
original parent first.

The ambiguity that I am trying to resolve comes not from a strictly
deterministic/non-deterministic sense of the word, but from the fact
that a programmer working in one module cannot with any degree of
certainty predict what will happen without full knowledge of what is
happening elsewhere. I think that is still true with Sam's proposed
changes.

I also think that the way that talloc_steal() can become a function
that effectively changes the reference count is also a big concern,
and not something I think we want.

There is another way we can approach this. It is clear that some
people want particular behaviour from talloc, and a one size fits all
may not be the right thing. So we could have inherited flags like
this:

  talloc_set_flag(ptr, TALLOC_FLAG_NO_REFERENCES);

if you set that inherited flag, then no references would be allowed in
this pointer of its children. That would address the concern that
talloc_steal() can fail with the changes I have made recently, as with
this flag set, talloc_steal() would not fail.

Similarly, we could have a flag:

  talloc_set_flag(ptr, TALLOC_FLAG_FREE_REF_FIRST);

which if set would tell talloc to use the old behaviour, freeing
references first, again guaranteeing that talloc_steal() will not
fail.

Whether adding these flags is a good idea is hard to tell. It may be
that it just causes more confusion, as the API would be different in
different parts of the code. Please let me know what you think.

Next issue - the .so version. The best solution I have heard on this
is from Metze, where he proposed to solve it in the packaging, by
creating a .so.1 package which links to the .so.2 package, providing
just the compatibility functions. That keeps the compatibility cruft
out of the main talloc code, and also puts the choice of how long to
keep these functions around squarely in the shared library packaging
area, so Simo can choose to keep them as long as he thinks they are
needed for Fedora. The main talloc code would switch to .so.2, as the
API and ABI have changed.

Metze, did you make any progress on implementing that? Does it work as
you expected it to?

Cheers, Tridge