Separate vote_router from active_transactions #4607
Conversation
There was a problem hiding this comment.
This is really cool. I can already see how this can be improved further with read/write locks to allow for faster multithreaded vote processing (no need for an exclusive mutex when we're not modifying the mapping). I struggled to get it done in the past when election routing was part of the AEC, but this makes it much easier.
| std::unique_lock lock{ mutex }; | ||
| for (auto const & [hash, _] : election.blocks ()) | ||
| { | ||
| elections.erase (hash); |
There was a problem hiding this comment.
Election object can hold a limited number of blocks and some can be dropped during its lifetime. While the cleanup thread should still clean up the remaining hashes, at first sight this might be confusing.
There was a problem hiding this comment.
Not sure if this directly helps but I renamed these to connect/disconnect to represent the looser ownership nature.
This change is to simplify the active_transactions class which has many responsibilities around election management. This change separates the responsibility of routing votes to their respective elections from other responsibilities inside active_transactions.
The mapping hash -> election in nano::active_transactions::blocks is moved into a new class nano::vote_router. Vote processing logic is moved from nano::active_transactions::vote to nano::vote_router::vote.
nano::vote_router changes the behavior from active_transactions::blocks in that it does not own the lifetime of elections. Only a weak_ptr to election is held and a background thread cleans up orphaned routes periodically.
nano::vote_code and nano::vote_source are moved into the vote_router.hpp file and forward declared when possible.