hmm.. Re: talloc issues

[Derrell Lipman]

On Mon, Aug 3, 2009 at 21:20, Rusty Russell <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 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; rather
each reference has a parent, so is freely reparentable by being stolen.

Derrell