[lawrencecchen]

Summary

R-DAEMON-STATE stage S1 step 6d (handoff/rewrites/R-DAEMON-STATE/DESIGN.md, section 2.6.1), from the review of the S1.7 default flip (#35413). Behind the stage switch CMUX_TUI_RDS_INPUT (only the input lane uses the port).

The defect. The person's keys cross their connection's three threads at user-interactive QoS (server/input_qos.rs, TYPING FIX 2 F7), then the terminal's input port writer, which was spawned at the default QoS and never raised itself. Under full CPU it waited for a CPU between the key's acceptance (daemon.send.written) and its write to the host. DESIGN 2.6.1 asks for the writer at user-interactive while it carries the person's input; it was listed after the #34544 review and not built. In the build 3b A/B (STATUS 11804), the lane-on keys over 4 ms waited in that hop (1.21-3.90 ms from daemon.send.written to the host's PTY write), and the lane-on tail was about 1 ms longer than the old path's.

The fix. The writer raises itself (input_qos::raise_this_thread, once per thread) when it takes a frame with no waiter that is not a viewer size: InputPort::enqueue, which only the person's keys use (InputReply::Accepted). Automation's writes (InputPort::write, a waiter) and viewer sizes do not raise it, so a port only automation writes to keeps the default QoS, as automation's connections do. A writer that exits idle starts again at the default. Off macOS this sets nothing.

Testing

Focused test (macOS only; QoS is a no-op elsewhere): the_input_ports_writer_runs_at_user_interactive_qos_once_it_carries_a_persons_key (surface/tests/hosted.rs). It checks that automation's write leaves the writer at the default QoS and that after a person's key the writer runs at user-interactive.

• Red at b078664 (test/rds-s16d-red-never-merge), fleet step b084ffa94c68fa603d5fd666 on aws-m4pro-3 (scripts/ci/cmux-tui-rust-check.sh --os macos test <name>): FAILED, "the writer that carried the person's key does not run at user-interactive QoS".
• Green at 3690c39, fleet step e95015db0fbec39e23d51602 on aws-m4pro-7: passed.
• Linux --filter hosted at 3690c39: run https://github.com/manaflow-ai/cmux/actions/runs/41839435510: test (linux) passed; lint (linux) was red on my test seam (writer_qos_for_test unused on Linux, where its macOS-only test does not exist).
• 0c77eb0 makes the seam cfg(all(test, target_os = "macos")) (test builds only). At this head, run https://github.com/manaflow-ai/cmux/actions/runs/41843138251: test (linux) passed; lint (linux) is red only on the base finding acpmux: clippy::indexing_slicing 687 > baseline 686 (a crate this PR does not touch; cmux-tui-core's counts went down).

Compile: fleet job 4ae6ea4a97f3bd342dc4ac5e at the head 0c77eb0: CmuxNext, app and cmux-tui passed (also bf8dbfe438eb0d68c30f6d19 at 3690c39).

Observed / Not run

• Observed: the fleet steps and the compile above.
• Not run: a typing A/B of this change alone. It runs in the S1.7 set (perf(cmux-tui-core): the input lane is the daemon's default; CMUX_TUI_RDS_INPUT=0 keeps the old path for one nightly (R-DAEMON-STATE S1.7) #35413), whose build contains it (build 9d7979ebda5282c4a6b0f152 at d62017f).

Changelog

none

Proof

No capture: a daemon thread priority, no UI.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the terminal input port's writer running at default QoS while carrying a person's keystrokes, so on macOS under full CPU a key no longer waits for a CPU between its acceptance and the write to the host.

• The writer raises itself to user-interactive QoS (once per thread) when it takes a frame with no waiter that isn't a viewer size — the path only the person's keys use.
• Automation's writes and viewer sizes don't raise it, so a port only automation writes to keeps the default QoS.
• Off macOS this sets nothing, and a writer that exits idle starts again at the default.

^{Written for commit 0c77eb0. Summary will update on new commits.}

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review 0c77eb0: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr35460 -f ref=fix/p0-typing-s1-6d-writer-qos -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4184857252001 (8c9aae8b0d)
• cmux NEXT nightly 1.0.0-nightly.4185261809301 (697838c74d)
• cmux NEXT nightly 1.0.0-nightly.4185464793401 (68821b04eb)
• cmux NEXT nightly 1.0.0-nightly.4185545977501 (b659812803)
• cmux NEXT nightly 1.0.0-nightly.4185901282301 (b8d9ef9cab)
• cmux NEXT nightly 1.0.0-nightly.4185979991201 (8a134ee405)
• cmux NEXT nightly 1.0.0-nightly.4186744784501 (890be4f45a)
• cmux NEXT nightly 1.0.0-nightly.4186855704101 (53421cdccd)
• cmux NEXT nightly 1.0.0-nightly.4187086980301 (df4454e051)
• cmux NEXT nightly 1.0.0-nightly.4188039004101 (3e464b08ff)
• cmux NEXT nightly 1.0.0-nightly.4190094575701 (036f8aa538)
• cmux NEXT nightly 1.0.0-nightly.4191131679101 (e01bbae5c9)

[lawrencecchen]

Review (claude-reviewer-rds-s16d): SHIP at 0c77eb0

R-DAEMON-STATE S1.6d. I read the code and the CI logs; I did not build or run anything. Paths are under cmux-tui/crates/cmux-tui-core/src/.

The change is correct. The port's writer raises itself to user-interactive QoS when it takes a person's key, before it writes that key. It does this after next_frame has released the port lock, so the port lock stays a leaf.

The lint fix at this head is correct. It changes only test code (3690c395049..0c77eb0ac59). The writer_qos field, its recording, writer_qos_for_test and the current_input_thread_qos re-export are now under cfg(all(test, target_os = "macos")). That removes the dead_code error that cmux-tui spec inventory reported at 3690c39 (run 41841804340), and that check passes at this head (run 41842954610). On Linux test builds, note_thread_qos still uses current_thread_qos.

Answers to your three questions

1. Is "no waiter and not a control frame" exactly the person's keys? Yes.

• Only two kinds of frames have no waiter. InputPort::enqueue makes waiter: None, control: false, and PortOrder::enqueue_after_pending makes control: true. InputPort::write always sets a waiter.
• The only non-test caller of enqueue is the InputReply::Accepted branch at surface/input.rs:109.
• Accepted comes only from cmd_terminal_io::input_surface, when the lane is on and the client types into the terminal. That is the same test that marks the connection's threads as the person's (mark_person_input).

2. Can a raised writer starve other work? No.

• The raised writer also writes automation's frames to that terminal at user-interactive QoS. That is the right choice: the port is one FIFO. Without it, a person's key behind an automation frame would wait for a default-QoS write, which is a priority inversion.
• The writer's CPU work is the frame copy and the system calls, and the port capacity (32 MiB) bounds it. Most of the time the writer waits in socket writes.

3. Does the per-thread RAISED flag work with a writer that exits idle? Yes.

• RAISED is thread-local. A writer that exits after 30 s idle ends its thread, and the next writer is a new thread with RAISED false. It raises itself again when it takes its first person frame.
• Nothing lowers a raised thread, so a writer stays raised for its life, as the connection threads do.

Notes (no change asked)

• The first person key can still wait behind automation frames. A writer that has not raised itself yet writes the frames queued ahead of the person's first key at default QoS. So in a port that automation used first, that key waits for those writes. One fix: enqueue sets a flag, and the writer reads it before each frame and raises itself. That would also cover those frames.
• Evidence that I could not see: the fleet Mac steps (b084ffa9 red, e95015db green) and the compile job.
• Checks still running: the focused run 41843138251 and cmux-next guards at this head.

[blacksmith-sh]

Found 3 test failures on Blacksmith runners:

Failures

Test	View Logs
nightly cmux-tui resolve/nightly cmux-tui resolve	View Logs
nightly.yml must not read vars.NIGHTLY_SIGN while nightly-sign.yml is in shadow mode/ nightly.yml must not read vars.NIGHTLY_SIGN while nightly-sign.yml is in shadow mode	View Logs
the short nightly decide gate must use the pooled Linux route with a Blacksmith fallbac k/ the short nightly decide gate must use the pooled Linux route with a Blacksmith fallbac k	View Logs

^{Need help on this PR? Tag @codesmith-bot with what you need.}