As part of #10270 I removed the page buffering schemed of a piped stdout in favor of a line buffering scheme. We will always want a line-buffering stdout at most for prints to a terminal, but when stdout is piped elsewhere we would ideally like to buffer more than just one line.
The reasoning for changing this is that diagnosing a runaway rust process becomes much more difficult with a buffered stdout. Most programmers are expecting some sort of line buffer, but very few consider flushing stdout after all of their lines have been printed as well. As a result, a program killed by a signal currently doesn't flush stdout, meaning that all of that output is lost. This output is likely very important for diagnosing why the process went awry in the first place.
I would like to turn this buffering back on, but not until we have a good solution for this fairly common case.
As part of #10270 I removed the page buffering schemed of a piped stdout in favor of a line buffering scheme. We will always want a line-buffering stdout at most for prints to a terminal, but when stdout is piped elsewhere we would ideally like to buffer more than just one line.
The reasoning for changing this is that diagnosing a runaway rust process becomes much more difficult with a buffered stdout. Most programmers are expecting some sort of line buffer, but very few consider flushing stdout after all of their lines have been printed as well. As a result, a program killed by a signal currently doesn't flush stdout, meaning that all of that output is lost. This output is likely very important for diagnosing why the process went awry in the first place.
I would like to turn this buffering back on, but not until we have a good solution for this fairly common case.