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:
|
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; |
|
// 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); |
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
pollas it looks like it's not possible with what node gives us:node-pty/src/unixTerminal.ts
Lines 200 to 211 in ccf6393
node-pty/src/unixTerminal.ts
Lines 224 to 232 in ccf6393