Prevent terminal query replies from blocking Emacs - #690

Tested this locally. It fixes the freeze, and I found one residual issue worth a follow-up.

Setup

Built both b46898e (PR head) and f1b03e5 (its base) from source with zig 0.16.0, -Doptimize=ReleaseFast, and ran each in a throwaway emacs -Q with ghostel-module-directory pointed at the respective build and load-path at the matching lisp/, so the elisp and the module never skew. macOS 25.6, Emacs 31.1, ghostel-use-native-pty t.

Wedge detection is an emacsclient --eval probe against a server-start in the test Emacs, with timeout; exit 124 means Emacs never got back to the command loop.

Results

The original reproduction from #689 (20,000 DSR queries interleaved with output, child never reads stdin):

The real-world shape that originally hit this — ssh as ghostel's direct pty child, with a full-screen TUI started on the far end:

Under the PR the remote TUI rendered correctly and Emacs stayed responsive throughout.

Regression checks

Both pass on the PR, so the zero-timeout give-up does not fire for programs that actually read their input:

• Plain DSR handshake, a program that queries and reads the reply: 5/5 replies received, identical on both builds.
• Busy-but-healthy TUI: 2,000 DSR queries interleaved with 400-byte output bursts, child draining stdin promptly. 2,000/2,000 replies received on both builds, zero dropped.

zig build test passes.

One residual: the drop is not all-or-nothing

ptyWriteFromTerminal advances offset across partial writes, so when the input queue fills mid-reply it abandons a half-written escape sequence in the child's input. The old code never did this, because it blocked until the whole reply landed — which is of course the freeze being fixed here.

Repro: fill the queue from a child that is not reading, then drain it and look at what is actually sitting there.

import sys, os, re, time, tty
fd = sys.stdin.fileno()
tty.setraw(fd)
w = sys.stdout.write
for _ in range(4000):                 # stuff the queue while never reading
    w('\x1b[6n'); w('z' * 100 + '\r\n')
sys.stdout.flush()
time.sleep(3)
os.set_blocking(fd, False)
buf = b''
end = time.time() + 5
while time.time() < end:
    try: buf += os.read(fd, 65536)
    except Exception: time.sleep(0.05)
whole = re.findall(rb'\x1b\[\d+;\d+R', buf)
leftover = re.sub(rb'\x1b\[\d+;\d+R', b'', buf)
print('bytes=%d well_formed=%d non_reply_bytes=%d\nleftover=%r'
      % (len(buf), len(whole), len(leftover), leftover[:64]))

On the PR build:

bytes=1022 well_formed=146 non_reply_bytes=4
leftover=b'\x1b[34'

That trailing ESC [ 3 4 is a DSR reply cut in half at the 1024-byte queue boundary. A TUI that recovers and resumes reading will treat it as the start of a sequence and swallow the next keystrokes into it.

Suggested narrowing: give up only at offset == 0, so a terminal reply is either written whole or not written at all. Partial delivery of a reply is never useful to the child.

None of this is a reason to hold the PR — a mangled escape sequence is a far better failure than a frozen editor. Happy to test a follow-up.

Thanks for testing. On the residual, I would decline the narrowing since that reintroduces the original bug. For a pathological child, this would again make it possible for it to block forever. I will merge this as is.