Re: [gdome]future memory management plans? (was: News(2) on CVS preparing 0.7.0)

[Paolo Casarini <casarini CS UniBO IT>]

On Fri, 9 Nov 2001, Tobias Peters wrote:

> 
> On Fri, 9 Nov 2001, Paolo Casarini wrote:
> > The idea is to use the Gdome_xml_Node.refcnt, the xmlNode.parent and the
> > xmlNode._private fields to understand if a Node and the subtree under
> > it is to be freed on unref.
> >
> > The n->parent field of a root node of a detached subtree is NULL, so when
> > the user call unref on such node and its refcnt reach 0 we can free its
> > xmlNode structure.
> >
> > We need n->_private to know which node of the subtree are to be freed:
> >
> > Example: suppose to have the follow detached subtree where the node A and
> > C are referenced each by one GdomeNode*.
> >
> > <A>        //referenced
> >   <B>
> >     <C>    //referenced
> >       <D/>
> >     </C>
> >   </B>
> >   <E/>
> > </A>
> >
> > When the user call unref on A we can free A, B and E libxml2 underling
> 
> Sorry, but you can't. The application could use its reference to C to
> access B (Node::parentNode), and recursively A and E. Just because there
> is no current reference to A does not mean the application does not want
> to create one in future.
> 
> Detached subtrees can only be freed completely. The only choice I see that
> you have is this:
> 
> (1) you can free the tree right then when the last reference to it is
>     going away.
>     Without a tree-level memory management this would involve a traversal
>     of the whole subtree until a referenced node is found (or none is
>     found).
>     The performance of this aproach is probably really bad.

Keeping the reference C is a feature in my mind... a simpler correct way
is to free all the subtree under A and invalidate the reference to C
(accessing it results in a GDOME_NULL_POINTER_ERR).

When you detach a subtree and destroy its root Element all the subtree
should be destroyed, even if there are refence to a Node in the
subtree: no DOM Implementation have different behaviour.

Bye,
   paolo. 
--
Paolo Casarini - casarini cs unibo it