Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COW radix tree #5

Closed
miekg opened this issue Jul 17, 2012 · 4 comments
Closed

COW radix tree #5

miekg opened this issue Jul 17, 2012 · 4 comments

Comments

@miekg
Copy link
Contributor

miekg commented Jul 17, 2012

To be really (really) useful a copy-on-write variant of radix would be nice. It will probably need a parental pointer in each node and ofcourse code that deals with the copy-on-write part.

@sauerbraten
Copy link
Owner

Mhm, I've never done COW, and don't quite see the sense. Would a COW radix mean that 2 callers read from the same tree, and if caller A makes changes to a node, a copy of that node is generated which is only visible to A? Or a copy of the whole tree? Why would I want changes to be only visible to one caller?

@miekg
Copy link
Contributor Author

miekg commented Jul 17, 2012

[ Quoting <reply+i-5657470-80779761e> in "Re: [radix] COW radix tree (#5)..." ]

Mhm, I've never done COW, and don't quite see the sense. Would a COW radix mean that 2 callers read from the same tree, and if caller A makes changes to a node, a copy of that node is generated which is only visible to A? Or a copy of the whole tree? Why would I want changes to be only visible to one caller?

COW is not about changes being visible to one caller, its about changes being
atomic for the readers. So both readers and writers can do what they want
and the tree (they see) will always be in a consistent state.

COW and tree means path copying as explained here:
http://hackerboss.com/copy-on-write-101-part-1-what-is-it/

... and the followup posts.

Regards,

Miek Gieben                                                   http://miek.nl

@sauerbraten
Copy link
Owner

Ok I got the point of COW for radix now. I believe we could get away without a parent pointer if we really want to implement it, though it would be a little bit 'dirty':
We could write a function GetPath(key string) (*Radix, []byte) {} which is similar to Find(), but adds the first char of the child it walks down into ( = the byte that is used in the children map) to a []byte which is returned with the *Radix, so we do not have to walk up the nodes when creating copies. Would that work?

Also, I'm thinking about writing a Find() function which uses a loop instead of recursion, so that appending bytes to the []byte would be easier. (The recursive way would need to pass the slice along on every call, wouldn't it?). Actually all the methods (Find(), Remove(), and Insert()) could be written using a loop. Is there any advantage in using recursion over loops?

@sauerbraten
Copy link
Owner

Couldn't find any usecase in which COW has a benefit. Closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants