[Spice-devel] [PATCH spice-server v2 2/3] Fix removing a node

[Frediano Ziglio]

> 
> On Wed, Nov 16, 2016 at 10:32:58AM -0500, Frediano Ziglio wrote:
> > > 
> > > In the short log, I'd talk about "node removal" rather than "removing a
> > > node"
> > > 
> > > On Wed, Nov 16, 2016 at 11:35:06AM +0000, Frediano Ziglio wrote:
> > > > Avoid to produce loop in the tree removing and adding nodes.
> > > > Unlink the node from the containing tree.
> > > > This possibly will create unlinked trees if a parent node is
> > > > deleted.
> > > 
> > > If I understand this correctly, the node was only invalidated, but was
> > > not removed from the tree contrary to what "stat_file_remove" implies.
> > > This means that the could then end up being reused, which would most
> > > likely corrupt the tree, or something like that?
> > > 
> > 
> > Yes, what was actually happening that the creation of loops
> > inside the tree caused some statistical function to go into
> > infinite loop (and reds_stat tool too).
> > I don't consider the removal (which is O(n)) a performance
> > problem as not in a hot path.
> > Currently no removal is called but as we are speaking
> > about implementing destroying objects this would have
> > raised as a problem later.
> > To optimize we could store somewhere (for instance using
> > the top bits in the flag field) the previous sibling or
> > the parent... or we could update the format of this file
> > I don't think it's a big issue.
> > 
> 
> Would be nice to have a more detailed commit log I guess..
> 
> Christophe
> 

Beside the consideration on performance with are OT, I think
the first sentence and your:

"What was happening is that the creation of loops inside
the tree caused some statistical function to go into an
infinite loop (and reds_stat tool too).

Nodes were only invalidated but still linked so when reused
the new node could point to a already existing node (like a
sibling) which pointed to the new reused one."

Frediano