feat(serial): POSIX 写超时加长 + 周期发送速率预警 - #8
Merged
Merged
Conversation
Exposed by hardware testing after RFC #3 Step 2: at 115200 8N1 a 2560 B / 100 ms scheduled send (25.6 KB/s) overruns the 11.52 KB/s line capacity and fails with 'Operation timed out' once the kernel TX buffer fills. - Backend: give the write handle a 1000 ms timeout on POSIX (timeout lives per-handle there, so the 50 ms read loop is unaffected). Windows shares COMMTIMEOUTS across cloned handles, so the write side keeps the builder value there. Per-poll timeout semantics mean borderline rates with bursts now drain instead of failing spuriously. - Frontend: SendPanel warns when a scheduled send's required rate exceeds 90% of the line capacity derived from baud/data/parity/stop bits, so physically impossible rates are flagged before the user hits timeouts. Remaining TX-queue work (write-behind thread, backpressure, failure reporting) tracked in #7 — needs RFC #3 Step 4 events as its channel.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_db63cf7c-c83e-4500-a20a-45d2dfd4312d) |
This was referenced Sep 2, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
RFC #3 Step 2 人工硬件测试暴露：115200 8N1 下 2560 字节 / 100ms 周期发送（需求 25.6 KB/s）超过线路物理容量（11.52 KB/s），内核 TX 缓冲区写满后
write_all阻塞超过端口 50ms 超时，弹Failed to send data: Operation timed out。物理超限无法根治，但可以①消除临界速率的误报②在配置阶段就提示用户。改动
serial_manager.rs）：POSIX 下写句柄超时 50ms → 1000ms。serialport 的超时是每次 poll 独立计时且存在每个 handle 结构体上，读循环的 50ms 不受影响。Windows 克隆句柄共享COMMTIMEOUTS，保持原值（代码内注释说明）。SendPanel）：周期发送需求速率 > 线路容量 90% 时显示 amber 预警（容量按 波特率 ÷ 每字节线位数 计算，含数据位/校验位/停止位；负载含 Hex 对数 / UTF-8 字节数 / 校验和长度）。中英 i18n。验证
cargo test32/32 全绿，零警告；npm run build通过范围外
TX write-behind 队列（背压 + 失败上报 + Windows 共享超时约束）→ #7，依赖 RFC #3 Step 4 事件通道。
Note
Medium Risk
Changes serial write timeout behavior on Unix (affects all TX) and adds client-side rate heuristics that may not match backend encoding exactly.
Overview
Addresses spurious send timeouts when bursty or large payloads fill the kernel TX buffer, and adds up-front UI feedback when periodic sending cannot physically keep up with the line.
On POSIX, the write handle’s port timeout is raised from 50 ms to 1000 ms after connect (read clone stays at 50 ms). Windows is unchanged because cloned handles share
COMMTIMEOUTS.SendPanel now receives
SerialConfigand, when scheduled sending is enabled, estimates line capacity (baud rate ÷ framing bits) and required send rate (payload bytes per interval, including checksum). If demand exceeds ~90% of capacity, an amber warning shows estimated rate vs capacity (en/zh i18n).Reviewed by Cursor Bugbot for commit edbdc39. Bugbot is set up for automated code reviews on this repo. Configure here.