native: Fix a possible deadlock in spawn #13080
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
The OSX bots have been deadlocking recently in the rustdoc tests. I have only been able to rarely reproduce the deadlock on my local setup. When reproduced, it looks like the child process is spinning on the malloc mutex, which I presume is locked with no other threads to unlock it. I'm not convinced that this is what's happening, because OSX should protect against this with pthread_atfork by default. Regardless, running as little code as possible in the child after fork() is normally a good idea anyway, so this commit moves all allocation to the parent process to run before the child executes. After running 6k iterations of rustdoc tests, this deadlocked twice before, and after 20k iterations afterwards, it never deadlocked. I draw the conclusion that this is either sweeping the bug under the rug, or it did indeed fix the underlying problem.
|
The no whitespace diff is much more pleasing to look at. |
bors
added a commit
that referenced
this pull request
Mar 24, 2014
The OSX bots have been deadlocking recently in the rustdoc tests. I have only been able to rarely reproduce the deadlock on my local setup. When reproduced, it looks like the child process is spinning on the malloc mutex, which I presume is locked with no other threads to unlock it. I'm not convinced that this is what's happening, because OSX should protect against this with pthread_atfork by default. Regardless, running as little code as possible in the child after fork() is normally a good idea anyway, so this commit moves all allocation to the parent process to run before the child executes. After running 6k iterations of rustdoc tests, this deadlocked twice before, and after 20k iterations afterwards, it never deadlocked. I draw the conclusion that this is either sweeping the bug under the rug, or it did indeed fix the underlying problem.
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jul 11, 2024
…-things, r=Alexendoo Lintcheck: Refactor structs and only take one version per crate For some time now I had the feeling that lintcheck's main file has been too large. This PR simply moves some structs into new submodules. I've also changed the `.toml` structure slightly to only accept one version per crate. AFAIK, we haven't use multiple versions before. If we want to test different versions, we can simply just add a second entry. That's what lintcheck does internally anyways. I wanted to have these changes in separate commits, but then accidentally squashed them... So sorry 😅 --- r? `@Alexendoo` If you think this is not really worth a proper review, since it's mostly a move refactoring in an internal tool, you can also `r=xFrednet` on this PR. changelog: none
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.
The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.
I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.
After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.