Problem
While a client waits for the server's ready byte, it polls with a 100 ms timeout and reopens the connect FIFO on every tick to check that the server is alive.
The timeout is there because macOS does not report FIFO peer death. On Linux, POLLERR fires at once on the rendezvous write end. On macOS nothing fires, so an untimed wait would hang forever when the server dies mid-handshake.
Code: Client::connect in crates/socket_ipc/src/unix.rs (added in #569).
Measurements
macOS 27, run bare and inside both the Codex CLI and Claude Code sandboxes:
| Watch |
Detects server death |
poll POLLERR/POLLHUP on connect write end |
no, times out |
kqueue EVFILT_WRITE EV_EOF on connect write end |
no, wakes writable without EV_EOF |
kqueue EVFILT_READ EV_EOF on response read end |
no, times out |
kqueue EVFILT_PROC NOTE_EXIT on the server pid |
yes, at once |
No FIFO event reports a dead peer on macOS. Watching the process is the only mechanism that works.
Also measured, in both sandboxes:
EVFILT_READ delivers the ready byte reliably when the read end is opened before any writer exists, which is the handshake order.- Registering
NOTE_EXIT on a pid that already exited returns ESRCH, so "server already gone" needs no extra race handling.
- Watching an unrelated same-user pid is allowed, so the client can watch the runner.
Proposal
Register EVFILT_READ on the response FIFO and EVFILT_PROC NOTE_EXIT on the server pid in one kqueue, then block in a single kevent with no timeout. The wait ends when the ready byte arrives or the server exits. The 100 ms tick and the reopen probe both go away.
The server publishes its pid next to the connection name.
Cost
- The connection name has to carry the server pid.
- A pid reuse window appears. If the server exits and the same pid is reused during the handshake, the watch follows the wrong process. Darwin cycles through the pid space before reuse, so this is remote, while the current probe asks the kernel about the exact FIFO and has no such window.
- macOS only. Linux keeps
POLLERR and already needs no timeout.
Priority
Low. The happy path already wakes immediately, so the timeout only adds latency when the server dies during the handshake, which is rare.
Problem
While a client waits for the server's ready byte, it polls with a 100 ms timeout and reopens the connect FIFO on every tick to check that the server is alive.
The timeout is there because macOS does not report FIFO peer death. On Linux,
POLLERRfires at once on the rendezvous write end. On macOS nothing fires, so an untimed wait would hang forever when the server dies mid-handshake.Code:
Client::connectincrates/socket_ipc/src/unix.rs(added in #569).Measurements
macOS 27, run bare and inside both the Codex CLI and Claude Code sandboxes:
pollPOLLERR/POLLHUPon connect write endEVFILT_WRITEEV_EOFon connect write endEV_EOFEVFILT_READEV_EOFon response read endEVFILT_PROCNOTE_EXITon the server pidNo FIFO event reports a dead peer on macOS. Watching the process is the only mechanism that works.
Also measured, in both sandboxes:
EVFILT_READdelivers the ready byte reliably when the read end is opened before any writer exists, which is the handshake order.NOTE_EXITon a pid that already exited returnsESRCH, so "server already gone" needs no extra race handling.Proposal
Register
EVFILT_READon the response FIFO andEVFILT_PROCNOTE_EXITon the server pid in one kqueue, then block in a singlekeventwith no timeout. The wait ends when the ready byte arrives or the server exits. The 100 ms tick and the reopen probe both go away.The server publishes its pid next to the connection name.
Cost
POLLERRand already needs no timeout.Priority
Low. The happy path already wakes immediately, so the timeout only adds latency when the server dies during the handshake, which is rare.