src: disable stdio buffering#7610
Merged
+5 −1
Conversation
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
bnoordhuis added c++ MemberAuthor
bnoordhuis commented Jul 8, 2016
CI: https://ci.nodejs.org/job/node-test-pull-request/3216/ smartos-64 stress test: https://ci.nodejs.org/job/node-stress-single-test/794/ |
Contributor
MylesBorins commented Jul 8, 2016
Should this be back ported to v4? |
Member
Trott commented Jul 8, 2016
Looks like it makes the test flaky again, so at a minimum, I guess this should mark the test flaky again in |
Member
Any chance the |
Member
addaleax commented Jul 8, 2016
@Trott I’d say its unrelated, thanks for pinging me on this, I’ll look into it. :) |
bnoordhuisforce-pushed the disable-stdio-buffering branch from 93aea92 to c2d15cbCompareMemberAuthor
bnoordhuis commented Jul 9, 2016
Test marked FLAKY. Can I get a LGTM? |
Member
addaleax commented Jul 9, 2016
LGTM |
1 similar comment
Member
Trott commented Jul 10, 2016
LGTM |
Member
Trott commented Jul 10, 2016
Running CI one more time mostly for confirmation of FreeBSD issue non-relevance: https://ci.nodejs.org/job/node-test-pull-request/3233/ |
MemberAuthor
bnoordhuis commented Jul 10, 2016
Java exceptions on the pi1-raspbian-wheezy buildbots. Haven't seen this one before...
Since they were green last time, I'll land this later today unless someone disagrees. |
Member
Trott commented Jul 10, 2016
|
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: nodejs#7610 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
bnoordhuisforce-pushed the disable-stdio-buffering branch from c2d15cb to cfe76f2CompareMemberAuthor
bnoordhuis commented Jul 11, 2016
@thealphanerd Eventually, but let's give it a little time. I'd like to see it go into one or two v6 releases first, just to check if it doesn't break anything. |
Contributor
MylesBorins commented Jul 11, 2016
sgtm @bnoordhuis |
evanlucas pushed a commit that referenced this pull request Jul 15, 2016
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Contributor
MylesBorins commented Oct 10, 2016
ping @bnoordhuis |
bnoordhuis added a commit to bnoordhuis/io.js that referenced this pull request Oct 20, 2016
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: nodejs#7610 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
MemberAuthor
bnoordhuis commented Oct 20, 2016
#9203 - cherry-pick to v4.x. |
MylesBorins pushed a commit that referenced this pull request Oct 24, 2016
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 26, 2016
Disable stdio buffering, it interacts poorly with printf() calls from elsewhere in the program (e.g., any logging from V8.) Unbreaks among other things the `--trace_debug_json` switch. Undoes commit 0966ab9 ("src: force line buffering for stderr"), which in retrospect is not a proper fix. Turning on line buffering fixed a flaky test on SmartOS but the test wasn't failing on other platforms, where stderr wasn't line-buffered either. Mark the test flaky again, it failed once in a run of 333 tries on the smartos-64 buildbot. Disabling buffering should be safe even when mixed with non-blocking stdio I/O because libuv goes to great lengths to reopen the tty file descriptors and falls back to blocking I/O when that fails. PR-URL: #7610 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Closed
Sign up for freeto 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.
Disable stdio buffering, it interacts poorly with printf() calls from
elsewhere in the program (e.g., any logging from V8.) Unbreaks among
other things the
--trace_debug_jsonswitch.Undoes commit 0966ab9 ("src: force line buffering for stderr"), which
in retrospect is not a proper fix. Turning on line buffering fixed a
flaky test on SmartOS but the test wasn't failing on other platforms,
where stderr wasn't line-buffered either.
Disabling buffering should be safe even when mixed with non-blocking
stdio I/O because libuv goes to great lengths to reopen the tty file
descriptors and falls back to blocking I/O when that fails.
R=@Trott?