Allowing a TTY to be both readable and writable.

[mcollina]

• Version: 1.20.0+
• Platform: Mac OS X, Linux

In versions < 1.20.0, libuv did not repsect the user stdio flags for new pipe, which was fixed in 8f9ba2a.
In Node.js both tty.ReadStream and tty.WriteStream are in fact Duplexes, with in theory one side closed. Because this was not enforced, both could work as a duplex.
This behavior has existed for so long that it might be considered a breaking change.

I think the best way to approach this is to add flags to uv_tty_init to support flags, so that we can create one that is both readable and writable at the same time and restore the behavior in Node.js.

[Fishrock123]

@cjihrig @bnoordhuis Any thoughts?

[cjihrig]

I think the best way to approach this is to add flags to uv_tty_init to support flags, so that we can create one that is both readable and writable at the same time and restore the behavior in Node.js.

That's pretty much what I said in nodejs/node#21654 (comment). However, it would require a new function or an ABI break (v2). I'd like some feedback on the idea from other collaborators before writing the code though - in case there is some significant reason for the current implementation that I'm not aware of.

[mcollina]

I think it’s not possible to support both flags on Windows. Is this something that libuv could support anyway?

IMHO there is no point in doing it only in libuv@2, as the regression in Node happened in a semver-minor. We are currently blocking backporting new libuv releases to Node 8.x.x because of this.

Should we deal with the problem in Node.js itself (nodejs/node#21654) or would we get a new function to support the previous behavior and fix the regression in Node 10?

[Fishrock123]

I think it’s not possible to support both flags on Windows. Is this something that libuv could support anyway?

You'd have to maintain some sort of written queue for that, I think? Like, how would you get the data unless you cached it?

[Fishrock123]

I'm wondering more and more if we shouldn't fix this in node... just make stdio a duplex from separate write/read fd streams on the stdio fd?

Unless someone has better insight I'm really not sure this makes sense for libuv due to Windows limitations?

[mcollina]

@Fishrock123 that’s not currently possible. In libuv a tty can either be a readable or a writable, not a duplex.

[Fishrock123]

@mcollina You can't make a separate readable and writable stream on the same FD anymore?

[mcollina]

We cannot create a duplex with uv_tty_init. We might go ahead and use two libuv handles. Could this work maybe?

[santigimeno]

I think it’s not possible to support both flags on Windows.

I'm not familiar with the tty code. Could you explain why?

We might go ahead and use two libuv handles. Could this work maybe?

This won't work. Libuv doesn't allow having multiple handles watching the same fd.

[vtjnash]

I think the best way to approach this is to add flags to uv_tty_init to support flags

On posix, I think we can also just query the OS for the correct flag values. Specifically, fcntl with the F_GETFL flag should return one of the O_ACCMODE=3 flags (O_RDONLY=0, O_WRONLY=1, or O_RDWR=2). I've been intending to make a patch to do this for a few months now, but we'll need to decide what to do with the user flags in that case (and figure out how to synchronize this with the Windows code).

I'm not familiar with the tty code. Could you explain why?

Looking at it briefly, it looks like it overlaps some state for reading and writing buffers, so you have to specify which way you intend to use it during construction. Perhaps worth reconsidering this now that Windows will soon have support for multiple (Pseude)Console handles though?

Currently, the libuv code specifically says:

/* TODO: put the parser states in an union - TTY handles are always half-duplex
 * so read-state can safely overlap write-state. */