use RWlock when accessing os::env #81850
Merged
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
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
bjorn3
reviewed
Feb 8, 2021
m-ou-se
reviewed
Feb 8, 2021
m-ou-se
reviewed
Feb 8, 2021
|
Is the common use case really massive read contention on the process environment? A mutex will be faster than an rwlock when uncontended. |
At least with glibc a lock or unlock is a single atomic RMW instruction as long as it is in read mode. A mutex can't do much better than that. That said, the contention I have observed is relatively small. It's the cause of about 1.9% of sampled context switches, which translates to an even smaller impact on wall time. |
m-ou-se
reviewed
Feb 9, 2021
|
(I was also about to comment on the names of the methods ( |
The enum is private though. Is there any reason to expose two different guards? |
|
It simplifies the code, and it's also what we do for |
This comment has been minimized.
This comment has been minimized.
|
Thanks! @bors r+ |
|
📌 Commit 4fc181d has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 11, 2021
use RWlock when accessing os::env Multiple threads modifying the current process environment is fairly uncommon. Optimize for the more common read case. r? ``@m-ou-se``
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 12, 2021
use RWlock when accessing os::env Multiple threads modifying the current process environment is fairly uncommon. Optimize for the more common read case. r? ```@m-ou-se```
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 13, 2021
Rollup of 10 pull requests Successful merges: - rust-lang#79775 (Fix injected errors when running doctests on a crate named after a keyword) - rust-lang#81012 (Stabilize the partition_point feature) - rust-lang#81479 (Allow casting mut array ref to mut ptr) - rust-lang#81506 (HWAddressSanitizer support) - rust-lang#81741 (Increment `self.index` before calling `Iterator::self.a.__iterator_ge…) - rust-lang#81850 (use RWlock when accessing os::env) - rust-lang#81911 (GAT/const_generics: Allow with_opt_const_param to return GAT param def_id) - rust-lang#82022 (Push a `char` instead of a `str` with len one into a String) - rust-lang#82023 (Remove unnecessary lint allow attrs on example) - rust-lang#82030 (Use `Iterator::all` instead of open-coding it) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 8, 2021
Revert switch of env locking to rwlock, to fix deadlock in process spawning This reverts commit 354f19c, reversing changes made to 0cfba2f. PR rust-lang#81850 switched the environment lock from a mutex to an rwlock. However, process spawning (when not able to use `posix_spawn`) locks the environment before forking, and unlocks it after forking (in both the parent and the child). With a mutex, this works (although probably not correct even with a mutex). With an rwlock, on at least some targets, unlocking in the child does not work correctly, resulting in a deadlock. This has manifested as CI hangs on i686 Linux; that target doesn't use `posix_spawn` in the CI environment due to the age of the installed C library (currently glibc 2.23). (Switching to `posix_spawn` would just mask this issue, though, which would still arise in any case that can't use `posix_spawn`.) Some additional cleanup of environment handling around process spawning may help, but for now, revert the PR and go back to a standard mutex. Fixes rust-lang#82221
the8472
added a commit
to the8472/rust
that referenced
this pull request
Mar 14, 2021
This reverts commit acdca31.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 15, 2021
use RWlock when accessing os::env (take 2) This reverts commit acdca31 (rust-lang#82877) i.e. redoes rust-lang#81850 since the invalid unlock attempts in the child process have been fixed in rust-lang#82949 r? `@joshtriplett`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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.
Multiple threads modifying the current process environment is fairly uncommon. Optimize for the more common read case.
r? @m-ou-se