Closed nagisa closed 3 months ago
I don't anticipate parallel writes to TrieUpdate
at all. The pipelined compilation/instantiation only needs access to potentially read out the contract code. While this may happen in a different thread, the timeline is strictly disjoint between threads seeing that specific TrieUpdate
...
In fact ideally we wouldn't deal with TrieUpdate
s here at all, but instantiation requires us to construct a full-featured VMLogic
that is going to be used for contract execution (including the entirety of the knowledge of how to read and write to the storage), so it kinda needs to exist early on...
Attention: Patch coverage is 79.14439%
with 39 lines
in your changes missing coverage. Please review.
Project coverage is 71.64%. Comparing base (
e5ad448
) to head (571a314
). Report is 11 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In a world where we have pipelined compilation, instantiation and execution,
VMLogic
will have to move between threads, which requires that it becomesSend
. It in turn has required some other types to become not onlySend
but alsoSync
due to them currently being stored as a&
reference (which allows for multiple copies, there are better places to explain whySync
becomes necessary here...)I'm not sure if all of these types will continue requiring
Sync
. In particularTrieUpdate
that's stored inRuntimeExt
is now by reference, but I eventually want to also makeVMLogic: 'static
, which would require finding some owning pointer structure that would work forTrieUpdate
... Or I might be able to use scoped threads... in which case we're looking atSync
anyway...I think the changes here are largely straightforward enough, but overall things are shaping to be pretty involved, eh?
Part of #11319