Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Use PVF code paired with executor params wherever possible #6742

Merged
merged 2 commits into from
Feb 20, 2023

Conversation

s0me0ne-unkn0wn
Copy link
Contributor

@s0me0ne-unkn0wn s0me0ne-unkn0wn commented Feb 17, 2023

Follow-up of #6161, closes #6724

The preparation pool and queue have been reworked.

The execution queue is untouched, as the PVF code and the executor params are handled separately there: executor params are per worker, and PVF is per job in the form of an already prepared artifact, so it doesn't make sense to pass plain code there.

Some questions I still have in mind:

  1. Should we keep the structure with the long name PvfWithExecutorParams for the sake of clarity or rename it back to just Pvf for the sake of conciseness;
  2. Are there any other points where it would be beneficial to pass ExecutorParams by reference (I abandoned the idea of passing it as so in queues as it causes lifetimes hell).

@s0me0ne-unkn0wn s0me0ne-unkn0wn added B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. labels Feb 17, 2023
@eskimor
Copy link
Member

eskimor commented Feb 17, 2023

For question one: Given that the initial structure was already not just the PVF (code), but also the hash I think it is fine to extend the structure further and keep its original name - or pick a different one altogether if it is confusing for some reason.

@@ -523,7 +523,7 @@ async fn handle_execute_pvf(
artifact: ArtifactPathId::new(artifact_id, cache_path),
execution_timeout,
params,
executor_params: pvf_with_params.executor_params(),
executor_params: (*pvf_with_params.executor_params()).clone(),
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is executor_params an Arc? I played around with removing it and it seems to work fine, and not having an Arc simplified a lot of these clones etc. Or am I missing something? 🙂

https://github.com/paritytech/polkadot/compare/s0me0ne/pvf-with-executor-params...mrcnski/no-arc?expand=1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Two considerations:

  1. I think you remember why that Arc appeared in the first place: because we want the whole structure to be easily clonable;
  2. There is already a method called code() (inherited from older Pvf struct) which returns Arc, and having two getters returning different types of references seems like an inconsistent design to me.

Probably you're right, and things shouldn't be overcomplicated here. I just need to either persuade myself it's okay or use some name like executor_params_as_ref().

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you remember why that Arc appeared in the first place: because we want the whole structure to be easily clonable

Oh right, I remember that now. It's even there in the docstring.

Copy link
Contributor

@mrcnski mrcnski left a comment

Choose a reason for hiding this comment

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

Very nice simplification, thank you! Just a couple questions.

Copy link
Contributor

@mrcnski mrcnski left a comment

Choose a reason for hiding this comment

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

Nice!

@s0me0ne-unkn0wn s0me0ne-unkn0wn merged commit d9c8e6c into master Feb 20, 2023
@s0me0ne-unkn0wn s0me0ne-unkn0wn deleted the s0me0ne/pvf-with-executor-params branch February 20, 2023 12:41
ordian added a commit that referenced this pull request Mar 16, 2023
* master: (98 commits)
  Ensure max_weight is assigned properly in AllowTopPaidExecutionFrom (#6787)
  Explicitly Handling ProvisionableData Cases (#6757)
  Companion for Substrate#12520 (#6730)
  Revert back to bare metal runners for weights generation (#6762)
  Improve XCM fuzzer (#6190)
  Corrected weight trader comment (#6752)
  clean up executed migrations (#6763)
  Remove state migration from westend runtime. (#6737)
  polkadot companion #12608 (Pools claim permissions) (#6753)
  Add Turboflakes bootnodes to Polkadot, Kusama and Westend (#6628)
  Companion for substrate#13284 (#6653)
  Companion for Substrate #13410: Introduce EnsureOrigin to democracy.propose (#6750)
  `BlockId` removal: `BlockBuilderProvider::new_block_at` (#6734)
  Companion PR for PR#13119 (#6683)
  Companion for Substrate#13411: frame/beefy: prune entries in set id session mapping (#6743)
  `BlockId` removal: refactor of runtime API (#6721)
  Fix auction bench (#6747)
  Use PVF code paired with executor params wherever possible (#6742)
  Retire `OldV1SessionInfo` (#6744)
  Companion for substrate #13121 - BEEFY Equivocations support (#6593)
  ...
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Always pass a PVF along with its executor params
3 participants