Make ClientIoMessage generic over the Client#10981
Conversation
Move the BlockInfo trait to new crate
Contains code extracted from ethcore that defines `Machine`, `Externalities` and other execution related code.
* master: Fix compiler warnings in util/io and upgrade to edition 2018 Upgrade mio to latest (#10953)
Initial version of extracted Engine trait
Cleanup Executed as exported from machine crate
Sort out default impls for EpochVerifier
* master: fix compile warnings (#10993)
| pub struct Service<T: 'static> { | ||
| client: Arc<Client<T>>, | ||
| io_service: IoService<ClientIoMessage>, | ||
| io_service: IoService<ClientIoMessage<()>>, |
There was a problem hiding this comment.
why is this ()?
does it work because we only care about ClientIoMessage::BlockVerified for the light client?
There was a problem hiding this comment.
Great question. So before this PR light depends on ethcore essentially only for ClientIoMessage, and then only because it has a Execute variant that embeds a Callback which is a Fn that takes an ethcore::Client as a param… So the dependency was actually not "real" but merely ceremonial, to satisfy the types as they were set up.
Once I made the Callback generic over the Client (and all the other types using it) @ordian spotted that it's actually not necessary to use anything other than () in light.
Now, we all agree that ClientIoMessage<()> looks plenty odd and hopefully someone will come along and refactor this further. ;)
In particular I know that @ngotchac is working on changes to the IO code that may, as a desired side-effect, result in a better message passing infrastructure, one that does not need a Client (or whatever stand-in we use).
There was a problem hiding this comment.
Ok, I see.
In particular I know that @ngotchac is working on changes to the IO code that may, as a desired side-effect, result in a better message passing infrastructure, one that does not need a Client (or whatever stand-in we use).
Cool 👍
niklasad1
added
A8-looksgood 🦄
…/eip-1884-reprice-trie-size-dependent-ops * dp/feature/eip-1344-add-ChainID-opcode: more merge fallout Update ethcore/vm/src/schedule.rs Fix a few warnings merge conflict error Make ClientIoMessage generic over the Client (#10981) bump spin to 0.5.2 (#10996) fix compile warnings (#10993) Fix compilation on recent nightlies (#10991) [ipfs] Convert to edition 2018 (#10979)
* master: EIP 1884 Re-pricing of trie-size dependent operations (openethereum#10992) xDai chain support and nodes list update (openethereum#10989) [trace] check mem diff within range (openethereum#11002) EIP-1344 Add CHAINID op-code (openethereum#10983) Make ClientIoMessage generic over the Client (openethereum#10981) bump spin to 0.5.2 (openethereum#10996) fix compile warnings (openethereum#10993)
3 participants
The one big remaining issue in ethcore is the
ClientIoMessagetype which has anExecutevariant that embeds aClient. This is a blocker for several things, e.g. making a freestandingethcore/light, extractingverificationetc.This PR attempts to disentangle this type by making it generic and extracts
verificationfromethcore.There are some questionable changes made here, in particular wrt to the traits used/modified. Careful review of these areas is much appreciated.
ImportBlocktrait gains a method despite theFIXMEthat seems to indicate that the trait should not even existTicktraitSnapshotClienttrait (maybe theSnapshotWritertrait should be combined with this?)making the light client's fetcher type param'static– better way?After this PR we can build the eth light client without depending on
Client.Based on #10978.
I have synced mainnet with this branch.