Skip to content
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

Round restart #288

Merged
merged 21 commits into from
Jul 17, 2021
Merged

Round restart #288

merged 21 commits into from
Jul 17, 2021

Conversation

kellpossible
Copy link

@kellpossible kellpossible commented Jun 20, 2021

Currently a work in progress:

TODO:

A number of refactors in this PR are related to #267

@kellpossible kellpossible changed the base branch from storage-locator-path-refactor to master July 4, 2021 10:17
@kellpossible kellpossible marked this pull request as ready for review July 12, 2021 12:33
@kellpossible kellpossible requested a review from jules July 12, 2021 12:34
@apruden2008
Copy link

@kellpossible are we separating the unfinished items into new issues?

@kellpossible
Copy link
Author

@apruden2008 I think so yes, I'll do that today, also I will properly report the problems that I encountered while testing the manual round restart in new issues

/// An enum containing a [Locator] or [LocatorPath].
///
/// **Note:** This can probably be refactored out in the future so
/// that we only use [Locator].

Choose a reason for hiding this comment

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

I will open an issue for this

Copy link

@jules jules left a comment

Choose a reason for hiding this comment

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

LGTM!

@kellpossible
Copy link
Author

kellpossible commented Jul 17, 2021

Pending a second review, and #308 hopefully this PR is good to go

.map(|(bucket_index, (participant, mut participant_info))| {
let bucket_id = bucket_index as u64;
let tasks = initialize_tasks(bucket_id, number_of_chunks, number_of_contributors as u64)?;
participant_info.restart_tasks(tasks, time)?;

Choose a reason for hiding this comment

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

It looks like one of the key parts of the change, is it? To reset the state of all contributors who is still in the round to the initial state similar to what we have on round start.

Copy link
Author

Choose a reason for hiding this comment

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

yep that's right

}));
// Restart the round because there are no verifiers
// left for this round.
let reset_round = self.current_verifiers.is_empty() && self.finished_verifiers.is_empty();

Choose a reason for hiding this comment

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

is it enough to have self.current_verifiers.is_empty()? Can you tell us more about the finished verifiers check here?

Copy link
Author

@kellpossible kellpossible Jul 17, 2021

Choose a reason for hiding this comment

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

The verifiers in the round get moved from the current_verifiers list to the finished_verifiers list when all their tasks are complete. If only checking current_verifiers and all the verifiers are considered complete for whatever reason, then the round will still be reset.

Copy link
Author

Choose a reason for hiding this comment

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

at least that's how I was understanding it

Copy link

@ibaryshnikov ibaryshnikov Jul 17, 2021

Choose a reason for hiding this comment

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

Is this case possible: one verifier finished, another one dropped?. This check will be produce false therefore.

Copy link
Author

@kellpossible kellpossible Jul 17, 2021

Choose a reason for hiding this comment

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

Thanks for raising questions about this line, I think it deserves more consideration.

Copy link
Author

Choose a reason for hiding this comment

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

I referenced it in #305

Copy link
Author

Choose a reason for hiding this comment

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

Yes it will produce false. Under the assumption that the remaining verifiers would be able to pick up the slack, but perhaps this isn't working yet and will be fixed in #305

@@ -783,13 +794,38 @@ impl Round {
}
}

/// Remove a contributor from the round.
pub(crate) fn remove_contributor_unsafe(

Choose a reason for hiding this comment

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

I hope we will remove "unsafe" and "try" from the function names one day. In case of remove_something_unsafe it's misleading because it's a safe function. And try_do_something() -> Result<...> doesn't need to have "try_" because it returns Result and it's clear that it can fail. And here the name is justified by the similarity to other remove_*_unsafe functions, which is ok for now.

Copy link
Author

@kellpossible kellpossible Jul 17, 2021

Choose a reason for hiding this comment

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

I agree, I was just following convention in this case. I'm not sure how we would express the intended meaning. The function may not fail with a result, but my guess is the original authors were trying to say that calling this function might be dangerous in the wrong contexts (without being "unsafe" according to the strict Rust definition).

Edit: updated after re-reading your comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
4 participants