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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel