std: Don't deadlock/panic on recursive prints#23798
Merged
Merged
Conversation
Contributor
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
alexcrichton
force-pushed
the
issue-23781
branch
from
0ccba19 to
2191701
Compare
Contributor
|
We could eventually use a re-entrant lock, as well, but this is fine for now. @bors: r+ 2191701 |
Collaborator
|
☔ The latest upstream changes (presumably #23796) made this pull request unmergeable. Please resolve the merge conflicts. |
Previously a panic was generated for recursive prints due to a double-borrow of a `RefCell`. This was solved by the second borrow's output being directed towards the global stdout instead of the per-thread stdout (still experimental functionality). After this functionality was altered, however, recursive prints still deadlocked due to the overridden `write_fmt` method which locked itself first and then wrote all the data. This was fixed by removing the override of the `write_fmt` method. This means that unlocked usage of `write!` on a `Stdout`/`Stderr` may be slower due to acquiring more locks, but it's easy to make more performant with a call to `.lock()`. Closes rust-lang#23781
alexcrichton
force-pushed
the
issue-23781
branch
from
2191701 to
e2fd2df
Compare
Member
Author
Collaborator
|
⌛ Testing commit e2fd2df with merge 9f9e251... |
bors
added a commit
that referenced
this pull request
Mar 28, 2015
Previously a panic was generated for recursive prints due to a double-borrow of a `RefCell`. This was solved by the second borrow's output being directed towards the global stdout instead of the per-thread stdout (still experimental functionality). After this functionality was altered, however, recursive prints still deadlocked due to the overridden `write_fmt` method which locked itself first and then wrote all the data. This was fixed by removing the override of the `write_fmt` method. This means that unlocked usage of `write!` on a `Stdout`/`Stderr` may be slower due to acquiring more locks, but it's easy to make more performant with a call to `.lock()`. Closes #23781
Collaborator
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Previously a panic was generated for recursive prints due to a double-borrow of
a
RefCell. This was solved by the second borrow's output being directedtowards the global stdout instead of the per-thread stdout (still experimental
functionality).
After this functionality was altered, however, recursive prints still deadlocked
due to the overridden
write_fmtmethod which locked itself first and thenwrote all the data. This was fixed by removing the override of the
write_fmtmethod. This means that unlocked usage of
write!on aStdout/Stderrmay beslower due to acquiring more locks, but it's easy to make more performant with a
call to
.lock().Closes #23781