3 ms·
To make these transactional too, they are actually stored in a different B tree. Cycles are avoided by not storing reference counts less than or equal to 1. Ho
by adrianratnapala 10y ago
To make these transactional too, they are actually stored in a different B tree. Cycles are avoided by not storing reference counts less than or equal to 1.
How does that work? If you don't store a refcount when it equals 1, how do you know not to delete the thing? And if you never delete anything, why keep refcounts?
- chrismorgan 10y agoWith a strong ownership model like Rust’s, the type system can essentially be used to handle the case of a ref count of zero or one. (I haven’t actually looked at the Sanakirja code.)
- pmeunier 10y agoAuthor here. So I thought when I started the project. But when you think more about it, Rust cannot allocate in an mmapped file, so you're basically on your own, and have to do plain old C-like memory management in the file, except that unlike in C, there is the extra constraint that everything is transactional, pulling the machine's plug needs to "unfree" all freed pages, and "unalloc" all allocated pages.
- pmeunier 10y agoGood question. The structure is a B tree. When you traverse it, and arrive to a block, but don't see it in the reference counting base, you know that it is referenced in the tree, so its reference count is at least 1. Then, if you want to free it, you have to delete all references to it in the tree. Maybe that blog post could have been more verbose about another feature of Sanakirja, the list of free pages.