This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix light client informant while syncing #9932
Fix light client informant while syncing #9932
Changes from all commits
a049111
054b73a
d53da11
f5821ec
a149a03
2025161
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 am not really sure about the usefulness of this struct, it seems that
set
function is only called once inset_state
of LightClient, since fields are private.Ok, I got it, it avoid bad use in future client inner implementation, maybe then we could move
is_idle
to it:and keep deref to
state
. Then we would have an easierset
function (without handle ref).This could be a bad idea if we need to keep is_idle mutex open (does not seems so).
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.
The thing is that you want to keep an open
SyncState
Mutex
whileis_idle
still being accessible. With the suggested changes, you cannot have a lock onSyncStateWrapper
(otherwiseis_idle
wouldn't be accessible), so you would have to expose the innerSyncState
lock, which could be used to directly change the state, without updatingis_idle
. Does that make sense?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.
Make sense, my suggestion was your second hypothesis (no mutex around SyncStateWrapper) , it does need to exposes the inner lock, on the other hand it keeps both locks together.
There is maybe less chance to mistake with current version, a mistake would be to pass any
&mut bool
toset_state
which would be clearly intentional.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 wonder whether there was a reason in #5002 not to take into account
verified_queue_size
https://github.com/paritytech/parity-ethereum/pull/5002/files#diff-e8c26f6188b2b873a7467abd3041b843R584
@rphmeier? Although that was a long time ago.
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.
Not sure about that. But from my local testing, it lead to wrong information being displayed (
Import
logs too soon)