Opening helix or neovim in `boo ui` freezes boo

[ldb]

boo freezes when running helix or neovim in a fresh session within boo ui.

Steps to reproduce:

1. Start boo ui
2. <Ctrl-a c> to create a new session
3. Start hx or nvim

Result: boo freezes.

Interestingly, this does not happen when I launch a boo new session and run helix or nvim there.
I can then use boo ui to take over this existing session without issues. However, launching a new session with helix or nvim will again freeze boo.

[kylecarbs]

Weird. I'll investigate ty!

[kylecarbs]

Found the issue - working on a fix now.

[kylecarbs]

@ldb I'm not certain my fix solves it.

Could you run BOO_LOG=/tmp/boo.txt boo ui and share the output here? That would help me figure this out.

[ldb]

I did, and launched helix within the new session. Again, boo ui froze. The log file ends up empty 🤔

/tmp $ cat boo.txt
/tmp $

[kylecarbs]

@ldb that empty log is actually the smoking gun: the ui froze inside a blocking syscall before it could write anything, which matches the deadlock below.

Confirmed root cause (a deadlock). Captured from a live frozen instance via the kernel (/proc/<pid>/stack, wchan):

• The session daemon was blocked in write() to a ui's control socket: unix_stream_sendmsg -> sock_alloc_send_pskb. The socket's send buffer was full because the ui wasn't draining it.
• All three boo ui processes were blocked in read() on that same daemon: unix_stream_recvmsg, waiting for the reply to their periodic info poll.

Both sides wait on each other: the daemon can't finish writing a large startup repaint (helix/nvim) until the ui reads, and the ui won't read because it's blocked waiting for an info reply the daemon hasn't sent yet. boo ls hangs for the same reason (it polls info for every session). It only triggers once the first repaint is large enough to fill the socket buffer, which is why a tiny window, or boo new followed by attach, doesn't reproduce it.

Fix: #89

1. The daemon's client writes are now non-blocking (queue, then flush on POLLOUT), so it never stalls on a slow ui and keeps draining the PTY.
2. As a safety net, boo ui's control polls are now time-bounded, so a stuck daemon can't freeze the ui. A timeout leaves the session in place, since slow is not dead.

Confirmed on Linux; the mechanism (unix-socket backpressure) is the same on macOS. A re-test once it lands would be appreciated.

Generated by Coder Agents on behalf of @kylecarbs.

[ldb]

Thank you, it works now and boo ui does no longer freeze when running helix. I noticed however that the system theme is not correctly passed to helix, I'll open a new issue for that.