Skip to content

Fix a deadlock in a libgreen test #11204

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

Merged
merged 1 commit into from
Dec 30, 2013
Merged

Conversation

alexcrichton
Copy link
Member

Turns out when you grab an OS mutex, you need to be careful about when and where
things are scheduled!

I've confirmed that I could fairly reliably get a deadlock (1 in 100 times ish) before this, and I cannot get a deadlock after this (after 1000+ runs).

Closes #11200

Turns out when you grab an OS mutex, you need to be careful about when and where
things are scheduled!
bors added a commit that referenced this pull request Dec 30, 2013
Turns out when you grab an OS mutex, you need to be careful about when and where
things are scheduled!

I've confirmed that I could fairly reliably get a deadlock (1 in 100 times ish) before this, and I cannot get a deadlock after this (after 1000+ runs).

Closes #11200
@bors bors closed this Dec 30, 2013
@bors bors merged commit b27c53b into rust-lang:master Dec 30, 2013
@alexcrichton alexcrichton deleted the issue-11200 branch January 1, 2014 21:30
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 24, 2023
new lint: [`should_panic_without_expect`]

Closes rust-lang#10956

changelog: new lint: [`should_panic_without_expect`]
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.

libgreen sched::test_spawn_sched_blocking is unstable
3 participants