-
Notifications
You must be signed in to change notification settings - Fork 646
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
Introduce freelist interface #773
Comments
High level makes sense. Eventually we should consider to deprecate the |
Admittedly, this interface was too idealistic for such an old codebase :) Turns out we're leaking implementation details everywhere and for some optimization also have introduced bad coupling. The tests are especially fun to decouple 🥇 Also the coupling of the transaction to the pages should not go into the freelist (imho) and we should have another mapping in the Tx that contains what pages have been allocated for it. Below seems like a functional interface, but I think we would need to cut this down a bit further to be practical.
source (not everything is implemented/updated yet): Do you want to continue through a PR? Happy to adjust and refactor the remaining pieces. |
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
I suggest to move all array related methods into a separate file |
Yes, I was able to work on it yesterday. I'll try to have something by the EOD. |
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
As mentioned in #772 (comment), the motivation of the refactoring is to achieve better testability and understandability (and accordingly better maintainability). Just submitted a PR #783, we still need to think more about it from test perspective. (test driven). We may also need to draft a document to summarize the data structure and the algorithms based on it, and also how we will test it. |
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]>
This introduces an interface for the freelist, splits it into two concrete implementations. fixes etcd-io#773 Signed-off-by: Thomas Jungblut <[email protected]> Signed-off-by: samuelbartels20 <[email protected]>
bbolt features two types of freelist: "array" and "hashmap". They are currently implemented in one monolithic struct, with their differences in functions separated into two go files.
Testing has been a pain so far, with many of the freelist details (i.e.releasing pages and serde to disk) leaking outside of the freelist struct. This makes reasoning about the implementations very difficult, too. Adding a new type of list is becoming increasingly cumbersome without a proper interface.
Quickly pulling out the existing functions into an interface could look like this:
Ideally we would move this into its own internal package in order to avoid leaking any more internals in the future. HashMap and Array should be two implementation as its own struct. Some shared functions (ie read/write) could be implemented in a common struct for now. Even though I expect those to become implementation dependent at some point, it seems quite inefficient to write low-digit uint64 integers without vint compression (or as a bitset), for example.
The text was updated successfully, but these errors were encountered: