Reader spins at 100% CPU for the rest of the run once a command closes stdout or stderr but keeps running

[matt-edmondson]

What's wrong

When a stream reaches end of stream, StreamReader.ReadAsync returns 0 immediately. ReadCallback (RunCommand/AsyncProcessStreamReader.cs:~160) ignores the 0, so the task completes. The loop at :79-96 sees IsCompleted and issues another read, which also returns 0 immediately. Task.WhenAny therefore never actually waits, and the loop busy-spins until process.HasExited.

Reproduction (Linux, net10.0, parent process CPU time)

Command	Wall	CPU
sh -c "sleep 3" (baseline)	3069 ms	73 ms
sh -c "exec 2>/dev/null; sleep 3"	3056 ms	3021 ms
sh -c "exec 1>&- 2>&-; sleep 3"	3048 ms	3030 ms

Why it matters

Any child that closes or redirects one of its streams and keeps running burns a full core in the caller for the whole run. Examples include daemons, wrappers that do exec 2>/dev/null, and tools that close stdout early. The cost scales with the command's duration.

Suggested fix

Have ReadAndCallback report end of stream (for example, return Task<bool>). Once a stream has ended, stop issuing reads for it: leave it out of WhenAny, or substitute a task that never completes. When both streams have ended, fall through to waiting for exit. The post-exit drain (:103-106) should also skip streams that have already ended.

Acceptance criteria

sh -c "exec 2>/dev/null; sleep 3" uses roughly baseline CPU, and output is still delivered completely for normal commands.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Medium. The caller burns a full core for as long as the child runs. Output stays correct, though, and only children that close or redirect a stream while they keep running trigger it.
• Area / suggested assignee: The read loop in AsyncProcessStreamReader (:79-106). Maintainer: @matt-edmondson.
• Duplicates: None. Related:
  • ExecuteAsync hangs forever (and leaves the child blocked) when the output handler throws or a strict encoding hits a decode error #89 is the same loop, but a hang when a read faults.
  • Output is silently truncated when a command writes more than about 8 KB that is still unread when it exits #84 and LineOutputHandler emits a spurious empty line when a CRLF line ending is split across two reads #85 are both addressed by open PRs.
• In progress: Possibly. Read each output stream to end of stream, not just until exit #87 ("Read each output stream to end of stream, not just until exit", fixes Output is silently truncated when a command writes more than about 8 KB that is still unread when it exits #84) replaces the while (!process.HasExited) + WhenAny loop with a ReadToEnd loop for each stream, and each loop ends when a read returns 0. That removes the busy-spin described here. Check this issue against Read each output stream to end of stream, not just until exit #87's branch before starting separate work.

Next steps: Once #87 lands, add the CPU-time repro (sh -c "exec 2>/dev/null; sleep 3") as a regression test, measuring process CPU time or counting reads, and close this issue if the test passes. If #87 does not land, apply the suggested end-of-stream handling in this issue.

---

Generated by Claude Code