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

Solve some nasty descheduling races with a lock #10817

Merged
merged 1 commit into from
Dec 5, 2013

Conversation

alexcrichton
Copy link
Member

Right now, as pointed out in #8132, it is very easy to introduce a subtle race
in the runtime. I believe that this is the cause of the current flakiness on the
bots.

I have taken the last idea mentioned in that issue which is to use a lock around
descheduling and context switching in order to solve this race.

Closes #8132

// the BlockedTask, then it may introduce a race where `f` is using the
// environment as well as the code after the 'deschedule' block.
//
// The solution we have chosen to adtop for now is to acquire a
Copy link
Contributor

Choose a reason for hiding this comment

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

typo: adopt

Right now, as pointed out in rust-lang#8132, it is very easy to introduce a subtle race
in the runtime. I believe that this is the cause of the current flakiness on the
bots.

I have taken the last idea mentioned in that issue which is to use a lock around
descheduling and context switching in order to solve this race.

Closes rust-lang#8132
@brson
Copy link
Contributor

brson commented Dec 5, 2013

We can probably optimize some context switches (like message passing) in the future by making an unlocked version.

bors added a commit that referenced this pull request Dec 5, 2013
Right now, as pointed out in #8132, it is very easy to introduce a subtle race
in the runtime. I believe that this is the cause of the current flakiness on the
bots.

I have taken the last idea mentioned in that issue which is to use a lock around
descheduling and context switching in order to solve this race.

Closes #8132
@bors bors closed this Dec 5, 2013
@bors bors merged commit be0580b into rust-lang:master Dec 5, 2013
@alexcrichton alexcrichton deleted the sched-fix branch December 6, 2013 03:19
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jun 2, 2023
validate lint name in `clippy_dev`

This PR adds a little bit of validation to `cargo dev new_lint`. I've had it happen a few times where I wanted to add a new lint, but forgot that lint names cannot contain `-`. If you try to do it anyway, `clippy_dev` will generate illegal syntax (like adding `mod test-lint;` to clippy_lints/src/lib.rs for the module declaration). Maybe having it error out early would be helpful to others too.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nasty hidden invariant in deschedule_running_task_and_then
4 participants