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

rust_port_detach is very inefficient #1924

Closed
brson opened this issue Mar 4, 2012 · 2 comments
Closed

rust_port_detach is very inefficient #1924

brson opened this issue Mar 4, 2012 · 2 comments
Assignees
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@brson
Copy link
Contributor

brson commented Mar 4, 2012

This function does a busy wait until there are no outstanding references to the port. I believe this is what's causing #1922 - under valgrind it serializes threads so we end up waiting a very long time.

@ghost ghost assigned brson Mar 4, 2012
@brson
Copy link
Contributor Author

brson commented Mar 5, 2012

I'm not sure how big a problem this is. It's obviously a big problem for valgrind, just based on the way valgrind works - callgrind shows it as taking up 50% of the running time on some benchmarks. In real multithreaded scenarios it is probably not nearly as bad. Still, it should be fixed just to reduce the cycle time on the linux bots.

@brson
Copy link
Contributor Author

brson commented Mar 8, 2012

Detaching now puts tasks to sleep as necessary instead of busy waiting.

@brson brson closed this as completed Mar 8, 2012
flip1995 pushed a commit to flip1995/rust that referenced this issue May 20, 2021
…ednet

`while_let_on_iterator` Improvements

fixes: rust-lang#6491
fixes: rust-lang#6231
fixes: rust-lang#5844
fixes: rust-lang#1924
fixes: rust-lang#1033

The check for whether a field can be borrowed should probably be moved to utils at some point, but it would require some cleanup work and knowing what parts can actually be shared.

changelog: Suggest `&mut iter` when the iterator is used after the loop.
changelog: Suggest `&mut iter` when the iterator is a field in a struct.
changelog: Don't lint when the iterator is a field in a struct, and the struct is used in the loop.
changelog: Lint when the loop is nested in another loop, but suggest `&mut iter` unless the iterator is from a local declared inside the loop.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

No branches or pull requests

1 participant