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

Christophe Fergeau cfergeau at redhat.com
Wed Nov 16 15:58:45 UTC 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20161116/598f4081/attachment.sig>


More information about the Spice-devel mailing list