hmm.. Re: talloc issues

[Sam Liddicott]

* Derrell Lipman wrote, On 04/08/09 15:07:
> On Mon, Aug 3, 2009 at 21:20, Rusty Russell <rusty at rustcorp.com.au
> <mailto:rusty at rustcorp.com.au>> wrote:
> 
>     > ..and talloc is the easiest way to reference count - you don't have to
>     > change your structs for a start, and you don't have to port to C++
>     either.
> 
>     I disagree.  To repeat myself, everyone needs to know you're using
>     references,
>     even independent code, so they don't simply talloc_free() something.
> 
> 
> I've seen this statement a few times during this discussion, and I don't
> get it. Someone decides that he needs to ensure that the memory doesn't
> go away until he's finished using it, so he creates an additional
> reference. From that point forward, no one should care whether they're
> working with the first reference to an allocated object or the Nth
> reference to the allocated object. All are equivalent; i.e. they all
> _reference_ the same object.

This much is true (glossing over "creates an additional reference" for
now); and the pointers are all exactly the same so you can't even tell
how they were obtained...

..but then something has to release once it is finished. If you need to
do it manually or you pass the pointer to an API that says it is going
to free explicitly, then it gets a little more complicated.

If you have some kind of ownership of your pointer (responsibility to
free it), then you need to get rid of it the reverse of how it was
obtained. If your pointer was obtained from talloc_reference(XXXX, ...;
then you need to talloc_unlink(XXXX,; if your pointer was obtained
through talloc_zero() or talloc_steal() then you probably need to call
talloc_free.

You don't have to worry about any of this if you don't need to
explicitly free the pointer.

> This should be perfectly analogous to a file system. Someone creates a
> file which allocates a unique inode. Someone else needs to ensure that
> the inode sticks around until they're finished using it so they create a
> hard link to that file. They have created a second reference to the same
> inode, thus increasing that inode's reference (link) count. Each
> reference to that file, the original name or the new name, points to the
> same inode. Either one can be freed (unlinked) at any time without
> concern for any other user of the inode and with no need to know that
> there are other references to the same inode. Each free (unlink)
> decrements the reference count of the inode. When the final reference is
> freed (unlinked), the inode's reference count goes to zero and the inode
> can be deallocated.
> 
> talloc() = creat()
> talloc_free() = unlink()
> talloc_reference() = link()
> talloc_unreference() = unlink()
> 
> and furthermore,
> 
> talloc_steal() = rename()
> 
> The allocated memory itself (the inode) has no concept of parent; 

this is not necessarily true with talloc. It doesn't HAVE to have an
idea of parent - you can make the parent NULL and all references owned
by NULL, and then you can just call talloc_unlink(NULL, pointer) - to
use your example.

But talloc is er... bigger; and there can be a parent - which is really
the main advantage because it means that most of the time you don't need
to worry about how to free something.

However this conversation is focussing around some samba4 code that does
a lot of explicit freeing (or stealing), but that is too complicated to
be re-written.

Sam