#10576: generic utility to unsubscribe from broadcast upon drop of the rx-side. (#10708)
* #10576: refactor `sc-utils::notification` and `sc-client-api::notifications`, so that they use common subscribe/unsubscribe routines * Add some docs. Reorganise `sc-utils::notification` * `sc-clent-api::notifications` and `sc-utils::notification` — ensure the SubscriptionGuard is dropped before the Rx-channel * `sc-utils::pubsub::SubscriptionGuard` make it a bit more ergonomic. Let the `Rx` to be put inside of the `SubscriptionGuard`, so that the latter shall guarantee the order: - first unsubscribe; - then drop the `Rx`. * Being less zealous with splitting the modules into little pieces * rework pubsub: the concrete usage should only define a good registry type * sc-client-api::notifications: make it comply with the reworked pubsub * cargo fmt * make sc-client-api tests work * Address the review notes * cargo fmt * Describe the behaviour of pubsub registry * Doc-comments for module `sc-utils::pubsub` * Fix: it used to send notifications regardless of the filter setup during subscription * `sc-client-api::StorageNotifications` the API does not have to require mut-self-reference. As a result `sc-service::Client` does not have to wrap its `storage_notifications` into a Mutex. * cargo fmt * Several changes addressing the notes by @bckhr. - Remove the `impl Default for StorageNotifications<Block>`; - no need for groupping the `remove_from` and `listen_from` into a separate `helpers` module; - remove unnecessary import `use registry::SubscribeOp`. * Add a doc-comment to the `sc-client::notifications::SubscribeOp` * As per @bkchr note on the unproven assertion: behave gracefully upon receiving a duplicate subscription-ID. * sc-utils::pubsub: log when a registry yields an ID that does point to an existing sink * `sc-utils::notifications`: payload materialized lazily * Update Cargo.lock (after adding `log` as a dependency to the `sc-utils`) * `sc-client-api::notifications`: introduce a struct (instead of a type def) for the notification message * Get rid of `sc-utils::pubsub::Channel` trait (instead just use the `sc-utils::mpsc`) * The SubsID is no more generic: the fact it is a `Copy` is known — no need to pass it by ref * sc-utils::pubsub internals do not have to be generic over the channel type * Rename Hub::dispatch into Hub::send * That method was unnecessary (`SubscriberSink::render_notification`) * cargo fmt * No need for a separate UnsubscribeGuard type * Ditch the type-def of SubsID in the sc-utils::pubsub, instead — just use the crate::id_sequence::SeqID * Return the <Registry as Dispatch>::Ret when sending an item * Make the `Hub<M, R>::lock_registry(...)` method more ergonomic * cargo doc links * cargo doc links * Use a simpler name for the type * cargo doc links * Derive `Default` rather than implement it * Derive `Default` rather than implement it * Remove an unnecessary usage of type_name * Define a more cautious order between sinks.remove->registry.unsubscribe and registry.subscribe->sinks.insert * Hub: lock_registry_for_tests->map_registry_for_tests — a safer choice for a public API * Replace Mutex over the shared Registry with a ReentrableMutex+RefCell * sc-utils::pubsub: add tests for a panicking registry * Add the missing copyright headers * Arc<Vec<_>> -> Arc<[_]>
Showing
- substrate/Cargo.lock 1 addition, 0 deletionssubstrate/Cargo.lock
- substrate/client/api/src/client.rs 4 additions, 4 deletionssubstrate/client/api/src/client.rs
- substrate/client/api/src/notifications.rs 48 additions, 568 deletionssubstrate/client/api/src/notifications.rs
- substrate/client/api/src/notifications/registry.rs 365 additions, 0 deletionssubstrate/client/api/src/notifications/registry.rs
- substrate/client/api/src/notifications/tests.rs 221 additions, 0 deletionssubstrate/client/api/src/notifications/tests.rs
- substrate/client/rpc/src/state/state_full.rs 2 additions, 2 deletionssubstrate/client/rpc/src/state/state_full.rs
- substrate/client/service/src/client/client.rs 4 additions, 4 deletionssubstrate/client/service/src/client/client.rs
- substrate/client/transaction-pool/api/src/lib.rs 1 addition, 1 deletionsubstrate/client/transaction-pool/api/src/lib.rs
- substrate/client/transaction-pool/tests/pool.rs 7 additions, 7 deletionssubstrate/client/transaction-pool/tests/pool.rs
- substrate/client/utils/Cargo.toml 1 addition, 0 deletionssubstrate/client/utils/Cargo.toml
- substrate/client/utils/src/id_sequence.rs 54 additions, 0 deletionssubstrate/client/utils/src/id_sequence.rs
- substrate/client/utils/src/lib.rs 2 additions, 0 deletionssubstrate/client/utils/src/lib.rs
- substrate/client/utils/src/notification.rs 57 additions, 86 deletionssubstrate/client/utils/src/notification.rs
- substrate/client/utils/src/notification/registry.rs 63 additions, 0 deletionssubstrate/client/utils/src/notification/registry.rs
- substrate/client/utils/src/notification/tests.rs 52 additions, 0 deletionssubstrate/client/utils/src/notification/tests.rs
- substrate/client/utils/src/pubsub.rs 263 additions, 0 deletionssubstrate/client/utils/src/pubsub.rs
- substrate/client/utils/src/pubsub/tests.rs 123 additions, 0 deletionssubstrate/client/utils/src/pubsub/tests.rs
- substrate/client/utils/src/pubsub/tests/normal_operation.rs 88 additions, 0 deletionssubstrate/client/utils/src/pubsub/tests/normal_operation.rs
- substrate/client/utils/src/pubsub/tests/panicking_registry.rs 248 additions, 0 deletions...trate/client/utils/src/pubsub/tests/panicking_registry.rs
Please register or sign in to comment