WIP: Rework block notification #92
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.
Currently, if a module wants to get blocks as they are accepted, they should pass in a channel to
chainstateand pool this channel for new blocks. That works fine for services (i.e: modules that have a loop watching stuff happening) but some modules might not be services, like the filters backend introduced in #89. This PR changes the subscription logic to "pass in an Arc-ed object that implementsBlockConsumer".It also implements a
Sync + Send + 'staticchannel that depends solely onalloc, and implementsBlockConsumer. Thestdmspcchannel receiver isn'tSend, making it tricky to use it acrossawaitpoints; using channels fromasync-std::channeladds the function coloring problem to the notification mechanism, which is undesirable. Moreover, we only need to send data from one source (ChainState) to one consumer (whoever wants to be notified), therefore a single source, single consumer channel is a perfect fit.