[QUICK] talloc bugs

[ronnie sahlberg]

On Mon, Jun 29, 2009 at 9:29 PM, Rusty Russell<rusty at rustcorp.com.au> wrote:
> On Mon, 29 Jun 2009 07:29:17 pm ronnie sahlberg wrote:
>> Example : A circular linked list. A circular linked list today with
>> talloc is treated as one meta-object owning the metadata for the list
>> och which all list elements are child objects to that linked list
>> metadata object. This can be argued to be a very unnatural hierarchy
>> for a list.
>
> Not at all.  The talloc hierarchy is a hierarchy of lifetimes, of ownership.
> This can overlap with the structural hierarchy.  Samba (ab)uses this in places
> to save on pointers to things which in practice are always talloc parents.
>
> But don't conflate the two!  Each node owning the next one is nonsensical.
>

Yes yes yes.
In a graph, there is no concept anymore of vertice X owns vertice Y.
They would just have "Object X references object Y". i.e.
talloc_reference(X, Y).
A graph has no concept at all of ownership of hierarchy.


Each node would NOT own the next node. In a graph no one owns any
other vertices. Each vertice is independent and equal to any other
vertice.
A vertice that becomes completely disconnected would however be
destroyed/freed when the last remaining edge to it is
talloc_unreference()d


Objects/vertices would merely have a reference to the next object, as
in this VERTICE has an EDGE connecting it to the next VERTICE. That is
the reference, The object has a pointer that connects to that other
object. Just as pointers are unidirectional in nature, a reference is
too.
But also, just as pointers, for example in the case of a circular
list, does not have any ownership concept, neither does references. A
reference merely describes that "this object refers to that other
object. If that other object dissapears we have to do something to
take care of this reference so it wont point out into binary void".
Neither the referrer or the referent have any owner/onwed concept.
They are both equal.
Just like a graph with two vertices and two edges, one edge in each
direction. The vertices depend on eachother and refer to eachother but
neither owns the other.



> Similarly, transferring ownership should be explicit.  register/unregister is
> a common pattern, which should *not* transfer ownership.  talloc_steal is
> dangerous in general because it's taking ownership: it only works if the givee
> is a parent of convenience.  Interfaces are usually better to take an explicit
> context argument, than using such a parent.

No,  no, no.
Forget about ownership. Ownership does not exist in a graph.

In a graph you dont have objects "owning" other objects. That only
makes sense in a tree where the parent can be thought of owning child
objects.
In a graph, all objects are equal, and the references merely refer to
which object refers to which other object. None of them are more equal
than any of the others.
Its like in AnimalFarm, all animals are equal. (except certain ones
that are more equal than others which happens when you introduce an
ownership concept into a graph)


In a graph you merely have edges/relations/references that connect two
equal objects/vertices together.
None is the parent of the other, none is more equal than the other,
the reference only describes that one object references the other and
in a sense depends on ti being not yet deallocated and disappearing
without first being told.

In a graph there is no concept of ownership or object X owns object Y.
That concept of ownership implies a tree structure, not a graph.
Dont think of it as ownership. It doesnt make sense with "ownership ==
parenthood".

It only makes sense in a pure graph where objects are VERTICES and
references are EDGES.
talloc_*_ref() creates a VERTICE.
talloc_reference/unreference() creates/removes an EDGE.

A VERTICE where the last EDGE is removed is physically free()d. I.e
when a VERTICE becomes completely disconnected it is automatically
free()d.



ronnie sahlberg