-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: split async/sync work in stages #4636
Conversation
e47ed97
to
2f582ed
Compare
2f582ed
to
661876f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great!
I like this a lot.
some style nits
4ffb880
to
0a456c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, some suggestions that could be done as followups
I'd also suggest renaming ExecInput to ExecContext?
{ | ||
input.checkpoint = Some(stage_progress); | ||
loop { | ||
poll_fn(|cx| exec_stage.poll_execute_ready(cx, input)).await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we add an extension trait with a helper function that does this:
https://docs.rs/tower/latest/tower/trait.ServiceExt.html#method.ready
but perhaps not worth it, maybe in a followup
pub consensus: Arc<dyn Consensus>, | ||
downloader: D, | ||
/// Block response buffer. | ||
buffer: Vec<BlockResponse>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these could probably be an Option, right?
with the assumption that calling execute before ready can panic
but this is fine
/// Database handle. | ||
provider: Provider, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this a lot, no more fiddling with the db types directly,
we could also box this I think
…, add header sync gap provider
1cc5a4c
to
9bb2e44
Compare
This is essentially just #4215 but renamed to better reflect what the PR will now be about.
Previously, most of the work in #4215 was to try and remove the
Send + Sync
bounds forDbTx
where possible to make it work with redb, however the transactions have since been madeSend + Sync
upstream so that is no longer needed.Instead, this will continue work on splitting async and sync work in the stages into two parts, inspired by
tower
'sService
trait: async work will be done inpoll_ready
, which will tell the caller when the stage is ready to be executed, and sync work (incl. writing to the database) will be performed inexecute
as normal.This will make it a lot clearer when things block and when they do not; most stages block in
execute
and do not really leverage async at all, some notable exceptions being the header and bodies stage.Assumptions
poll_ready
is only required to be called beforeexecute
(Rebasing newer work and pushing in a bit)