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

Clean up controller signals to improve abstraction #1996

Merged
merged 19 commits into from
Dec 19, 2023

Conversation

linh2931
Copy link
Member

@linh2931 linh2931 commented Dec 17, 2023

Currently controller signals an all-purpose block_state_legacy_ptr for accepted_block_header, accepted_block, and irreversible_block. block_state_legacy_ptr is passed across functions, hiding actual parameters a function needs. Over 40 files depend on block_state_legacy.hpp.

This PR

  • Changed to signal types which are only required.
  • Changed function interface to use exact parameters instead of one-for-all block_state_legacy_ptr and updated implementation
  • Updated tests
  • Removed unused signals pre_accepted_block, accepted_transaction, and bad_alloc.

Those changes

  • help make Instant Finality coding simpler by removing the need to signal variant types,
  • reduce abstraction leakage,
  • reduce the overall codebase dependency on to-be-obsolete block_state_legacy_ptr by removing the majority uses of it.

Resolved #1957

Comment on lines 330 to 332
signal<void(std::tuple<const signed_block_ptr&, const block_id_type&, const signed_block_header&, uint32_t>)> accepted_block_header;
signal<void(std::tuple<const signed_block_ptr&, const block_id_type&, const signed_block_header&, uint32_t>)> accepted_block;
signal<void(std::tuple<const signed_block_ptr&, const block_id_type&, uint32_t>)> irreversible_block;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would create a type:
using block_signal_params_t = std::tuple<const signed_block_ptr&, const block_id_type&, const signed_block_header&, uint32_t>;

And use the same type for all 3 signals.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Will change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why signed_block_header. When is signed_block_header != static_cast<signed_block_header>(*signed_block_ptr) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no reason for uint32_t block_num. The user can just use signed_block_ptr->block_num(). The id is included because calculate_id() is expensive, but block_num() I think is efficient enough we don't need to include it in the signal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to use signed_block_header and block_num explicitly for calling out parameters required by signal clients and for easier review to make sure nothing is missed during the changes. But we need to strike some balances between the number of parameters to signal and abstraction leakage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@linh2931 linh2931 requested a review from heifner December 19, 2023 15:11
@linh2931 linh2931 changed the title Clean up controller signals to improve Clean up controller signals to improve abstraction Dec 19, 2023
@linh2931 linh2931 merged commit 9924152 into main Dec 19, 2023
@linh2931 linh2931 deleted the clean_up_controller_signalling branch December 19, 2023 17:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Signal signed_block_ptr and block_id instead of block_state_ptr
3 participants