compiletest: Run tests in their own thread to avoid blocking the schedul... #8531
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| run_metrics(config, testfile, &mut _mm); | ||
| let config = Cell::new(config); | ||
| let testfile = Cell::new(testfile); | ||
| // XXX: Creating another thread to run the test because this |
There was a problem hiding this comment.
Could this be tagged with 6436?
…duler The calls to waitpid are interacting badly with the message passing that goes on between schedulers and causing us to have very little parallelism in the test suite. I don't fully understand the sequence of events that causes the problem here but clearly blocking on waitpid is something that a well-behaved task should not be doing. Unfortunately this adds quite a bit of overhead to each test: one thread, two tasks, three stacks, so there's a tradeoff. The time to execute run-pass on my 4-core machine goes from ~750s to ~300s.
|
@alexcrichton yes, done. @graydon yes, this should not be a problem when we use libuv's async process spawning. Note that reverting work stealing also added parellelism back to compiletest, something that I wouldn't expect if the problem is waitpid blocking scheduler message passing. Perhaps though work stealing is sending messages in different patterns that are not being responded to in a timely way. |
bors
added a commit
that referenced
this pull request
Aug 17, 2013
...er I believe the calls to waitpid are interacting badly with the message passing that goes on between schedulers and causing us to have very little parallelism in the test suite. I don't fully understand the sequence of events that causes the problem here but clearly blocking on waitpid is something that a well-behaved task should not be doing. Unfortunately this adds quite a bit of overhead to each test: one thread, two tasks, three stacks, so there's a tradeoff. The time to execute run-pass on my 4-core machine goes from ~750s to ~300s. This should have a pretty good impact on cycle times. cc @toddaaro
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 25, 2024
…t-edit, r=Veykril feat: Support multiple tab stops for completions in VSCode Uses the native VSCode support for `SnippetTextEdit`s. Fixes rust-lang#13229 and fixes rust-lang#8531. https://github.com/rust-lang/rust-analyzer/assets/13354275/a2d2c033-bb30-4f34-92ca-bf3f4f744cdc This is done in a slightly hacky way, as `vscode-languageclient` can't convert RA's `SnippetTextEdit`s into vscode `SnippetTextEdit`s and will appear to use a [different format](https://github.com/microsoft/vscode-languageserver-node/blob/295aaa393fda8ecce110c38880a00466b9320e63/types/src/main.ts#L1501-L1516) in the future. --- ~~Marked as draft since as-is, this will cause completions to double-indent any multi-line code generated.~~ **Update:** This also fixes up edits so that any multi-line code won't be double-indented.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...er
I believe the calls to waitpid are interacting badly with the message passing that goes
on between schedulers and causing us to have very little parallelism in
the test suite. I don't fully understand the sequence of events that causes
the problem here but clearly blocking on waitpid is something that a
well-behaved task should not be doing.
Unfortunately this adds quite a bit of overhead to each test: one thread, two
tasks, three stacks, so there's a tradeoff. The time to execute run-pass on
my 4-core machine goes from ~750s to ~300s.
This should have a pretty good impact on cycle times.
cc @toddaaro