Concurrency on Luther Monson

os/exec's StdoutPipe Footgun: How cmd.Wait() Ate My Last Frame (Twice)

Thu, 17 Sep 2026 20:12:00 -0700

shipmates spends most of its life spawning claude (and codex) processes and reading newline-delimited JSON off their stdout. The last frame of a turn is the important one. It’s a result frame with the cost, the model and the final text. Stderr matters too, because that’s where Claude Code tells you Invalid API key · Please run /login. For a while I was throwing both away under load. The cause is documented right there in the os/exec godoc. I fixed it in one package and then found the exact same bug again a month later in another.

Stop Running PHP on tokio's spawn_blocking - Own Your Thread Pool

Fri, 04 Sep 2026 20:30:00 -0700

For most of its life, ePHPm ran every PHP request on tokio’s spawn_blocking pool. It works. It passes tests and it serves benchmarks fine. It’s the first thing anybody reaches for when they need to call blocking code from async Rust. It’s also quietly wrong for a language runtime. The problems only show up under overload or after a crash. Over the last three weeks it got replaced with a pool of OS threads that ePHPm owns. That pool shipped first behind a config flag, then as the default. As of v0.9.0 the spawn_blocking engine is gone.

Two Small go-proxmox Fixes: A Watch Channel That Never Closed, and WithRetry

Sat, 11 Jul 2026 17:26:00 -0700

Here are two changes from the v0.5 to v0.7 stretch of go-proxmox. They’re too small for a post each. They’re worth knowing about if you write long-running tooling against Proxmox. One is a bug in code I wrote about in 2022. The other is a feature that replaces a retry loop everybody was writing for themselves.

The channel that only closed when things went well

In 2022 I wrote up how tasks and Watch work. Watch returns a channel of log lines. A goroutine tails the task log until the task stops. Then it closes the channel so you can range over it. Here is the tail loop from that post: