fix(src): prevent boo ui freeze from daemon write deadlock

[kylecarbs]

Fixes #85.

Summary

boo ui froze when opening helix/nvim in a freshly created session. The root cause is a daemon-side blocking-write deadlock, now confirmed on Linux with kernel evidence from a live frozen instance (below).

Root cause (confirmed)

The session daemon (src/daemon.zig) runs a single-threaded poll(2) loop and wrote to clients with blocking writes (conn.send -> protocol.writeMsg -> writeAll -> posix.write). Meanwhile boo ui does synchronous, un-timed client.control("info") round-trips for every session every 250ms (refreshSessions), with a blocking read and no deadline.

When a session produces a large startup repaint (helix/nvim on an 85x144 viewport, x3 UIs), the daemon's socket send buffer to a ui fills before the ui drains it, and the daemon blocks in write(). That ui is simultaneously blocked reading an info reply from the same daemon. Neither side makes progress: a mutual deadlock. boo ls hangs for the same reason (it infos every session).

Kernel evidence from the reporter's live frozen instance (NixOS):

process	state	syscall / wchan
daemon (pid 2444987)	D/S	write(fd 7) -> unix_stream_sendmsg -> sock_alloc_send_pskb (send buffer full, peer not draining)
boo ui x3	S	read(...) -> unix_stream_recvmsg (the info round-trip)

This did not reproduce with small test viewports (tiny repaints). The real setup had large viewports and three concurrent UIs, which is enough to fill the send buffer.

The fix

Two changes; the first removes the deadlock, the second is a client-side safety net.

1. Non-blocking daemon writes (src/daemon.zig, src/protocol.zig)

• Accepted client sockets are O_NONBLOCK.
• conn.send queues frames (protocol.appendMsg) and flushes what the socket accepts now; the remainder goes out on POLLOUT.
• A client that backs up past a generous cap (8 MiB) is dropped (it reconnects and gets a fresh repaint) instead of being buffered without bound.
• Final frames (detach, exit, replies) drain through a bounded shutdown flush.
• sweep recomputes passthrough after dropping a client so the window answers its own queries once no client remains.

The daemon never blocks on a slow client again; it keeps draining the PTY and answering control commands.

2. Time-bound boo ui control round-trips (src/client.zig, src/main.zig, src/ui.zig)

• client.control gains an optional timeout_ms: it polls the socket with a deadline before each read and returns error.Timeout if no reply arrives.
• The ui passes a 3s control_timeout_ms for its sidebar polls (info, cwd, rename, quit); the CLI passes null to preserve its blocking semantics (boo wait already polls client-side).
• A timeout never deletes the socket: a slow daemon is not a dead one, so sessionInfo and killSession keep the session rather than orphaning a live one.

Even if a daemon ever stops answering for another reason, the ui now gives up and stays interactive instead of freezing.

Testing

• zig build test-all in Debug and -Doptimize=ReleaseSafe: 214/214 pass, including 3 new unit tests (non-blocking queue/flush order, cap-drop, and control timeout).
• zig fmt --check clean.
• Smoke test: boo new -d, ls, peek, kill all work.

Implementation notes

• protocol.appendMsg frames a message into a growable buffer (the queue), parallel to writeMsg.
• Conn gains out (queue), out_cap, and a shutdown flag so final frames drain before close; flush does partial, non-blocking writes and compacts the buffer; drop discards and marks the conn dead.
• The loop registers POLLOUT only when output is queued and flushes before handling input.
• drainOutbound gives queued finals a bounded (250ms) chance to land at teardown.
• client.control's deadline uses poll() per read; the new test binds a listening unix socket that never accept()s, so the reply read blocks and must time out.

Generated by Coder Agents on behalf of @kylecarbs.