CI: https://ci.nodejs.org/job/node-test-commit/8701/
CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/673

I'll update the original today if desired

@Fishrock123 Do whatever makes the most sense to you, I just did this because I’d like to see it land in time for 8.0.0

ok so maybe I don't have enough time / interest... carry on I guess

I don't think it makes any sense to block only on fd 0-2 though...

Plus that changes the behavior in yet another way 😬

If anyone doesn't want to block on their own FD, they can just call the method?

I don't think it makes any sense to block only on fd 0-2 though...

By that logic all Node.js streams should be blocking by default… these problems are about stdio, and that will cover the vast majority of all TTY streams.

Also, there’s similar code in lib/net.js for new net.Socket() already.

If anyone doesn't want to block on their own FD, they can just call the method?

Then we should add something for that to the public API.

By that logic all Node.js streams should be blocking by default… these problems are about stdio, and that will cover the vast majority of all TTY streams.

if you don't block to TTYs the same silly (esp interleaving) problems manifest. Was there any issue with it behaving as it has been? I am -1 on changing that to be async by default in some cases.

if you don't block to TTYs the same silly (esp interleaving) problems manifest.

Again, that’s true for any stream if you open it multiple times? Also, what’s special about stdio is that the API (and console.* in particular) encourages you to act like the writes are synchronous…

I’m dropping 889239b24f1237e69c5b4fdcc1f5df10586a94ec from this PR though, let’s save this discussion for something less time-constrained…

Landed in 1b63fa1