-
Notifications
You must be signed in to change notification settings - Fork 22
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
Remove changes that failed to process from seen map #230
Conversation
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.
Replacing the Mutex with simpler logic should make a smaller, more performant, code change.
error!("could not process multiple changes: {e}"); | ||
for change in changes { | ||
let v = *change.0.versions().start(); | ||
seen_mutex.lock().remove(&(change.0.actor_id, v)); |
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.
Adding a mutex here is probably a bit harder than changing the return value of the future and handling it in the loop, in the tokio::select!
.
For example, you could return BTreeMap<ActorId, RangeInclusiveSet<Version>>
(or something) from the future. It would represent the data to remove from the seen map. You'd only do this if the function errored, else you return an empty BTreeMap
(does not allocate).
@@ -461,11 +473,8 @@ pub async fn handle_changes( | |||
|
|||
// process these first, we don't care about the result, | |||
// but we need to drain it to free up concurrency | |||
res = join_set.join_next(), if !join_set.is_empty() => { | |||
_ = join_set.join_next(), if !join_set.is_empty() => { |
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.
Here, you'd handle the map, remove every element present in it, from seen
.
No description provided.