frame-benchmarking-cli: Remove native dispatch requirement (#14474)

* frame-benchmarking-cli: Remove native dispatch requirement

No need for this, we can just use the `WasmExecutor` directly.

* Fixes

* Pass benchmarking host functions

* Ensure we can pass custom host functions
This commit is contained in:
Bastian Köcher
2023-06-29 17:56:25 +02:00
committed by GitHub
parent 0e58bd91b6
commit 83caca85b6
20 changed files with 117 additions and 119 deletions
+4 -4
View File
@@ -1152,10 +1152,10 @@ where
// Verification for imported blocks is skipped in two cases:
// 1. When importing blocks below the last finalized block during network initial
// synchronization.
// 2. When importing whole state we don't calculate epoch descriptor, but rather
// read it from the state after import. We also skip all verifications
// because there's no parent state and we trust the sync module to verify
// that the state is correct and finalized.
// 2. When importing whole state we don't calculate epoch descriptor, but rather read it
// from the state after import. We also skip all verifications because there's no
// parent state and we trust the sync module to verify that the state is correct and
// finalized.
return Ok(block)
}
@@ -78,11 +78,11 @@ pub(crate) struct VoterOracle<B: Block> {
///
/// There are three voter states coresponding to three queue states:
/// 1. voter uninitialized: queue empty,
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized:
/// queue has ONE element, the 'current session' where `mandatory_done == true`,
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized: queue has ONE
/// element, the 'current session' where `mandatory_done == true`,
/// 3. lagging behind GRANDPA: queue has [1, N] elements, where all `mandatory_done == false`.
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's
/// popped off the queue, eventually getting to state `2. up-to-date`.
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's popped
/// off the queue, eventually getting to state `2. up-to-date`.
sessions: VecDeque<Rounds<B>>,
/// Min delta in block numbers between two blocks, BEEFY should vote on.
min_block_delta: u32,
@@ -84,19 +84,17 @@ use std::{
/// the API of this behaviour and towards the peerset manager is aggregated in
/// the following way:
///
/// 1. The enabled/disabled status is the same across all connections, as
/// decided by the peerset manager.
/// 2. `send_packet` and `write_notification` always send all data over
/// the same connection to preserve the ordering provided by the transport,
/// as long as that connection is open. If it closes, a second open
/// connection may take over, if one exists, but that case should be no
/// different than a single connection failing and being re-established
/// in terms of potential reordering and dropped messages. Messages can
/// be received on any connection.
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the
/// first connection reports `NotifsHandlerOut::OpenResultOk`.
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the
/// last connection reports `NotifsHandlerOut::ClosedResult`.
/// 1. The enabled/disabled status is the same across all connections, as decided by the peerset
/// manager.
/// 2. `send_packet` and `write_notification` always send all data over the same connection to
/// preserve the ordering provided by the transport, as long as that connection is open. If it
/// closes, a second open connection may take over, if one exists, but that case should be no
/// different than a single connection failing and being re-established in terms of potential
/// reordering and dropped messages. Messages can be received on any connection.
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the first connection
/// reports `NotifsHandlerOut::OpenResultOk`.
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the last connection
/// reports `NotifsHandlerOut::ClosedResult`.
///
/// In this way, the number of actual established connections to the peer is
/// an implementation detail of this behaviour. Note that, in practice and at
@@ -402,9 +402,9 @@ pub trait NetworkNotification {
/// a receiver. With a `NotificationSender` at hand, sending a notification is done in two
/// steps:
///
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
/// for another notification, yielding a [`NotificationSenderReady`] token.
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
/// can only fail if the underlying notification substream or connection has suddenly closed.
///
/// An error is returned by [`NotificationSenderReady::send`] if there exists no open
@@ -192,12 +192,10 @@ pub struct Finalized<Hash> {
/// The event generated by the `follow` method.
///
/// The events are generated in the following order:
/// 1. Initialized - generated only once to signal the
/// latest finalized block
/// 1. Initialized - generated only once to signal the latest finalized block
/// 2. NewBlock - a new block was added.
/// 3. BestBlockChanged - indicate that the best block
/// is now the one from this event. The block was
/// announced priorly with the `NewBlock` event.
/// 3. BestBlockChanged - indicate that the best block is now the one from this event. The block was
/// announced priorly with the `NewBlock` event.
/// 4. Finalized - State the finalized and pruned blocks.
#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]