Issue drafted by Claude (Fable 5), an LLM by Anthropic, at andy5995's direction.
Queued socket output is stranded, or silently dropped, whenever the state machine leaves ONLINE. Found while reviewing #84, and documented there as a @warning on m2k_pending_to_line() rather than fixed, because repairing it changes the state machine.
Three related paths, each reproduced against the branch build:
- Stranded after
+++. The escape leaves the socket alive with bytes in the socket write buffer, but CMD state never polls that socket for POLLOUT, so nothing sends them. They sit there until ATO, and stepping does not move them.
- Stranded after carrier loss.
stepEnterCmd() resets the command buffer and the DTE-side read buffer, but not the socket write buffer, so the residue of a dead connection persists into CMD.
- Dropped on ATO.
stepEnterOnline() calls sockBufWReset(), which is right for a fresh connection but discards exactly the bytes the escape stranded when it is resuming an existing one.
The visible effect is that a host draining before teardown cannot tell "sent" from "discarded", and an unbounded drain loop never terminates.
Roughly what a fix looks like: poll and flush the socket write buffer from CMD state while the connection is alive; reset it on connection teardown instead of on entry to ONLINE, so a fresh call still starts clean while ATO preserves what was queued.
m2k_pending_to_dte() has the mirror of the first problem: nothing drains the DTE-side write buffer once the machine reaches M2K_STATE_DONE, so a PTY host whose comm program exited with output still queued has no way to flush it.
Queued socket output is stranded, or silently dropped, whenever the state machine leaves ONLINE. Found while reviewing #84, and documented there as a
@warningonm2k_pending_to_line()rather than fixed, because repairing it changes the state machine.Three related paths, each reproduced against the branch build:
+++. The escape leaves the socket alive with bytes in the socket write buffer, but CMD state never polls that socket forPOLLOUT, so nothing sends them. They sit there until ATO, and stepping does not move them.stepEnterCmd()resets the command buffer and the DTE-side read buffer, but not the socket write buffer, so the residue of a dead connection persists into CMD.stepEnterOnline()callssockBufWReset(), which is right for a fresh connection but discards exactly the bytes the escape stranded when it is resuming an existing one.The visible effect is that a host draining before teardown cannot tell "sent" from "discarded", and an unbounded drain loop never terminates.
Roughly what a fix looks like: poll and flush the socket write buffer from CMD state while the connection is alive; reset it on connection teardown instead of on entry to ONLINE, so a fresh call still starts clean while ATO preserves what was queued.
m2k_pending_to_dte()has the mirror of the first problem: nothing drains the DTE-side write buffer once the machine reachesM2K_STATE_DONE, so a PTY host whose comm program exited with output still queued has no way to flush it.