On Wed, Nov 16, 2016 at 10:50:30AM -0500, Frediano Ziglio wrote: > > > > 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." "to an already" fine with me otherwise. Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel