-
Notifications
You must be signed in to change notification settings - Fork 339
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
limit the number of retries of the busy handler #963
Conversation
e2035bd
to
ab00329
Compare
ab00329
to
b372068
Compare
let mut maybe_state_slot = self.state.slot.write(); | ||
// We need to make sure that the state slot is our slot before removing it. | ||
if let Some(ref state_slot) = *maybe_state_slot { | ||
if Arc::ptr_eq(state_slot, &old_slot) { |
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.
is there a case where a pointer gets reused and we run into a ABA problem?
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.
no, we discussed that last time, but we're actually comparing the pointer with itself, and we're still holding a reference to both ends while comparing, so no risk of it being reused in the meantime :)
// We check that slot wasn't already stolen, and that their is still a slot. | ||
// The ordering is relaxed because the atomic is only set under the slot lock. |
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 comment can probably go away, no?
if !*is_stolen { | ||
lock.rollback(); | ||
} | ||
*is_stolen = true; |
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.
Shouldn't this be in opposite order?
let stolen = *is_stolen
*is_stolen = true;
if !stolen {
lock.rollback();
}
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.
no, think of it as "if not already stolen, then rollback, then mark as stolen"
e6099f9
to
82c13b4
Compare
82c13b4
to
8c0c079
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.
looks good, later we can also push a low priority follow-up that brings back AtomicBool
, since it's probably just as good -- and test it on canary
* limit the amount of retries for the lock stealer * use mutex for `is_stolen` * unconditionally update state after execute * shorten watch channel borrow * fmt
This PR fixes a series of bugs that caused hangs on the platform.
is_stolen
AtomicBool
by aMutex<bool>
. I'm not sure this one was necessary, but I was desperate.borrow_and_update
in a channel was borrowing too long, causing a dead_lock. This was caused by some obscure rules about temporaries, causing the reference to be dropped after the call, even though it was being dereferenced. This is best exemplified by https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3c7bf7fbc2471c9bce121c781ebc982b, and elements of explanation can be found here: https://blog.m-ou.se/super-let/