Investigate replacing the setTimeouts in the backpressure handling

[Tyriar]

After #831, performance is way better for 50kb it takes around 500ms (down from ~5s). Kitty and Ghostty both handle it seemingly instantaneously, we should strive for that.

This likely needs a C++ solution like poll as it looks like it's not possible with what node gives us:

node-pty/src/unixTerminal.ts

Lines 200 to 211 in ccf6393

	case -35: // EAGAIN (macOS)
	case -11: // EAGAIN (Linux)
	// This error appears to get swallowed and translated into
	// `ERR_SYSTEM_ERROR` when using tty.WriteStream and not fs.write
	// directly.
	// This can happen during a regular partial write, but the most
	// reliable way to test this is to run `sleep 10` in the shell and
	// paste enough data to fill the kernel-level buffer. Once the sleep
	// ends, the pty should accept the data again. Re-process after a
	// short break.
	this._writeTimeout = setTimeout(() => this._processWriteQueue(), 5);
	return;

node-pty/src/unixTerminal.ts

Lines 224 to 232 in ccf6393

	// Using `setImmediate` here appears to corrupt the data, this may be what
	// the interleaving/dropped data comment is about in Node.js' tty module:
	// https://github.com/nodejs/node/blob/4cac2b94bed4bf02810be054e8f63c0048c66564/lib/tty.js#L106C1-L111C34
	//
	// Yielding via `setImmediate` also doesn't seem to drain the buffer much
	// anyway, so use a short timeout when this happens instead. Note that the `drain`
	// event does not appear to happen on `net.Socket`/`tty.WriteStream` when
	// writing to ptys.
	this._writeTimeout = setTimeout(() => this._processWriteQueue(), 5);

[Tyriar]

At least for non-blocking, polling on POLLOUT this checks writable not flushed so it doesn't end up working for the same reason setImmediate doesn't. At least when using node.js' fs.write/streams as non-blocking writes are written async via the libuv threadpool.

[Tyriar]

Hacked on this for a while but it's not worth the effort for me to go further at this point. I explored non-blocking/blocking, using Napi::AsyncWorker or std threads for writes, and also moving read also to C++. After getting past some deadlocks it all ended up being a similar speed at the cost of maintainability and the interleaving problem would still occur.

Marked as help wanted, feel free to investigate this if you're interested and more knowledgeable in the area 🙏

[Tyriar]

Something I discovered recently after fixing the main issue that required VS Code to throttle in (#831) is that I since I was actually testing in bash 3.2*, which uses cooked mode by default not raw mode like most shells. What's become clear from that is that these timeouts are actually only necessary for cooked mode, and maybe macOS only (I suspect a kernel bug, haven't checked if it impacts Linux yet).

So it looks like we'll be able to remove the setTimeout when adding data without an error totally and move to setImmediate on EAGAIN. We'll be able to do a targeted fix specifically for cooked mode to handle this to prevent the data corruption.

* This is the really old version that ships in macOS that they haven't touched since moving to zsh by default. I typically work using defaults since most users don't bother updating and I'll switch between zsh and bash.

---

A lot of terminals seem to have this interleaving problem so we're actually behaving better than them currently. Same test as in the details block mentioned in #831 used for the screenshots below.

VS Code:

Terminal.app (throttles similar in speed to what we were doing originally) works:

iTerm2 (throttles but faster than Terminal.app):

kitty:

ghostty:

[Tyriar]

ghostty discussion: ghostty-org/ghostty#9939
kitty issue: kovidgoyal/kitty#9295

[Tyriar]

This actually might not be cooked mode at all and instead an old bash readline bug, so we don't need to and shouldn't fix it at all.