refactor: extract kbuckets into separate structure #1494
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was wrong?
The
kbuckets
are widely used and they are wrapped inArc<RwLock<>>
for asynchronous access.This can be dangerous combination as it's easy to hold the
kbuckets
lock and try to acquire some other lock or do.await
. This was the root problem of the #1390 .How was it fixed?
I wrapped
Arc<RwLock<KBucketsTable<NodeId, Node>>>
in a structure (that I namedSharedKBucketsTable
).Every time lock is acquired, it's held only for the minimum amount of time, during one function call.
This approached is recommended in https://draft.ryhl.io/blog/shared-mutable-state/ , which is referenced from: https://tokio.rs/tokio/tutorial/shared-state#restructure-your-code-to-not-hold-the-lock-across-an-await
I tried to minimize functionality changes. Here are highlights:
interested_enrs
andbatch_interested_enrs
are just moved fromgossip.rs
insert_or_update_discovered_nodes
- re-implementation of previousOverlayService::process_discovered_enrs
nodes_by_distance
- original implementation wasn't working correctlyKBucketsTable::nodes_by_distances
but it would potentially later filter entries, resulting in returning less results than desiredNote: While this PR is big, I would say that at least 2/3 are test related changes. If desired, I can try to split it up into smaller PRs for easier review.
To-Do