docs(net): N-32 P2a 落地记录 + 修正设计文档的 P2 原计划
§5/§9 的 P2 更新为「P2a ✅ 已落地 / P2b 建议暂缓」，并记录一条**实测
推翻原计划**的修正：原清单要求删掉 net_recv_locked / net_pending_tick /
net_accept_locked 三处即时重建，实测删掉会引入回归（CLOSED 窗口拉长 →
调用方高频空转 net_accept → uiTask 最坏单轮 172ms→1034ms + task stall），
故只删对账③④ 两处**周期性**路径，保留三处**消费者驱动**路径。
同时如实记录两项观测：
- `task stall` 为**既有现象**（P1 基线同条件 53 条 vs P2a 32 条，未恶化），
故原判据「风暴期间无 task stall」不可用，已标注；
- uiTask 最坏单轮历史最大值 P2a 偏高（1054ms vs 172ms），但当前值
（uil=10999µs）正常，判为一次性卡顿，留待观察。
P2b（同步忙等改造）建议暂缓：实测忙等的危害是理论性的（未改造时 task
stall 同样存在），而 net_close 是热路径，按 Trap 25 不为此动热路径。
This commit is contained in:
@@ -174,17 +174,22 @@ B10 行）→ 中断丢了，bit3=0 同样停在已关/半关态，孤儿 Socket
|
||||
断连 → 断言 sink 仍拿到 EOF、且**下一个客户端能被服务**（当前会被旧会话静默吸收）。
|
||||
回归矩阵沿用 B10 那套（`:7003` 10/10、`:21` 50/50×2、`:8888` 20/20、`ftp_regression` 11/11、Trap 23 5/5×2）。
|
||||
|
||||
### P2 单一所有者（中改，消灭多所有者）
|
||||
### P2 单一所有者（中改，消灭多所有者）—— P2a ✅ 2026-10-12 / P2b 建议暂缓
|
||||
|
||||
1. 新增 `net_listener_pump()`，与 `net_reconcile_tick` 同处 netTask 自愈节拍，
|
||||
是**唯一**对监听型 Socket 调 `net_relisten_try` 的地方。
|
||||
2. 删除散点 relisten 调用：`net_accept_locked:1346`、`net_recv_locked:1884`、`net_pending_tick:2451`
|
||||
——它们只报告 EOF，重建由 pump 统一做（消除"抢先"这件事本身）。
|
||||
3. 消灭 netTask 内的同步忙等（U6）：`net_close_locked:2597-2616` 的 500 ms `osDelay` 循环、
|
||||
`net_listen_locked:1115-1126` 的 3×500 ms，改用既有 D10 非阻塞重试模式。
|
||||
4. 补 U11：本层 CLOSED 而芯片**正在** LISTEN → 只做状态重同步（等价 `NET_MSG_RESYNC_LISTEN`），不重下发命令。
|
||||
5. 验收：close/listen 风暴期间无 `[WD] task stall`；`:21` 0ms×50 仍 50/50；
|
||||
`netp`（`net_poll` 段最长耗时，µs）不劣化。
|
||||
1. 新增 `net_listener_pump()`（100 ms 周期），接管**周期性**重建，是唯一做周期性
|
||||
`net_relisten_try` 的地方。✅ 已落地
|
||||
2. ⚠ **原第 2 条已被实测推翻**：原计划「删除 `net_accept_locked` / `net_recv_locked` /
|
||||
`net_pending_tick` 三处即时重建」。实测删掉会把 CLOSED 窗口从 ~0 拉长到 ~100 ms，
|
||||
调用方高频空转 `net_accept`（RPC 无上界）→ uiTask 最坏单轮 172 ms → 1034 ms + `[WD] task stall`。
|
||||
**故保留这三处**（消费者动作触发，非周期性抢先），只删对账③④ 两处**周期性**路径。
|
||||
调用点 7 → 5。✅ 已按修正版落地（详见 §9）
|
||||
3. P2b：消灭 netTask 内的同步忙等（U6）：`net_close_locked` 的 500 ms `osDelay` 循环、
|
||||
`net_listen_locked` 的 3×500 ms，改用既有 D10 非阻塞重试模式。
|
||||
**建议暂缓** —— 实测 `task stall` 在忙等未改造时同样存在，危害是理论性的（详见 §9）
|
||||
4. 补 U11：本层 CLOSED 而芯片**正在** LISTEN → 只做状态重同步，不重下发命令。✅ 已落地
|
||||
5. 验收：`:21` 0ms×50 仍 50/50；`netp`（`net_poll` 段最长耗时，µs）不劣化。✅ 见 §9
|
||||
（⚠ 原判据「close/listen 风暴期间无 `[WD] task stall`」**不可用**：该现象在基线同样存在，
|
||||
见 §9 的 P1/P2a 对比数据）
|
||||
|
||||
### P3 远期（**不建议现在做**，仅登记方向）
|
||||
|
||||
@@ -315,11 +320,37 @@ RAM 预算台账 `.md`，属另一在途任务）。这两个文件在主工作
|
||||
工作树里没有故必报红（机理见 `docs/环境与部署/并行任务工作树方案.md` §10.2）。
|
||||
待该任务合入后自动消解，**不应**由本分支代为提交他人半成品。
|
||||
|
||||
**P2（单一所有者）**
|
||||
- [ ] 新增 `net_listener_pump()`，与 `net_reconcile_tick` 同节拍，成为**唯一**调 `net_relisten_try` 的监听重建入口
|
||||
- [ ] 删散点 relisten：`net_accept_locked:1346`、`net_recv_locked:1884`、`net_pending_tick:2451`
|
||||
- [ ] 消灭 netTask 内同步忙等：`net_close_locked:2597-2616`（500 ms `osDelay` 循环）、`net_listen_locked:1115-1126`（3×500 ms）→ 改 D10 非阻塞重试
|
||||
- [ ] 补 U11：本层 CLOSED 而芯片**正在** LISTEN → 只做状态重同步，不重下发命令
|
||||
- [ ] 验收：close/listen 风暴期间无 `[WD] task stall`；`:21 0ms×50` 仍 50/50；`netp`（`net_poll` 段最长耗时 µs）不劣化
|
||||
**P2（单一所有者）—— 已拆为 P2a / P2b**
|
||||
|
||||
**回滚点**：P0 纯注释可直接 revert；P1 若回归失败 revert 单提交即可（④ 仍在，退回到"端口活着但慢消费者可能卡死"的已知状态）；P2 涉及入口收口，须按阶段各自成提交、各自可 revert。
|
||||
**P2a（✅ 2026-10-12 落地，提交 `7cb5af0`）**
|
||||
- [x] 新增 `net_listener_pump()`（100 ms 周期 + 去抖 + 冷却），接管**周期性**重建，
|
||||
覆盖：① LISTENING 失位 ② CLOSED 不在 LISTEN ③ CLOSED 但芯片**正在** LISTEN（U11）
|
||||
- [x] 删对账③④ 及其孤儿态认领门槛（对账只剩①②；认领收窄为 ESTABLISHED/LISTENING）
|
||||
- [x] 补 U11：本层 CLOSED 而芯片正在 LISTEN → **只做状态重同步**（含 `last_peer_port`
|
||||
转登 + `lost_conn_seen` 清零，同 `net_resync_listen`），不发任何芯片命令
|
||||
- [x] `net_listener_armed` 收紧：CLOSED 态仅在 `readable≠0`（有残留）时放行
|
||||
- [x] 验收：`:21` 0ms×50 / 100ms×50 各 **50/50**；`:8888` **20/20**；`:7003` 300ms×10
|
||||
**10/10**；`ftp_regression` **11/11**；Trap23 abort/graceful 各 **5/5**；
|
||||
设备侧 `orphan listener` 增量 **0**（P1 基线同条件为 **2**）→ 目标达成
|
||||
|
||||
- [ ] **P2b（同步忙等改造）—— 建议暂缓**：`net_close_locked` 的 500 ms `osDelay` 循环、
|
||||
`net_listen_locked` 的 3×500 ms。**实测依据**：全量历史 `task stall` 在忙等未改造时
|
||||
同样存在（P1 基线同条件 53 条），忙等的危害是**理论性**的；而 `net_close` 是每次会话
|
||||
结束都走的热路径。按 Trap 25「不留未证明的复杂度」，为一个未发生的故障去动热路径，
|
||||
性价比存疑 —— 建议等有 `task stall` 与忙等的**因果证据**后再做。
|
||||
|
||||
> ⚠ **P2a 与设计文档原清单的关键差异（实测推翻原计划，务必据实执行）**：
|
||||
> 原清单第 2 条要求把 `net_recv_locked` / `net_pending_tick` / `net_accept_locked`
|
||||
> **三处即时重建一并删除**。台架实测证明**删掉会引入回归**：
|
||||
> - CLOSED 窗口从 ~0 拉长到 pump 周期 + 隔离期（~100 ms）；
|
||||
> - 期间调用方高频发起 `net_accept`（RPC：入队 + `xTaskNotifyWait` 回执**无上界**）
|
||||
> → 队列积压 → 实测 uiTask 最坏单轮 **172 ms → 1034 ms**，`[WD] task stall` 出现；
|
||||
> - 故**保留这三处**：它们是「**消费者动作触发**」（消费者正在等这条连接的结局），
|
||||
> 不是周期性「抢先」；真正该收敛的只有**周期性**路径（对账③④）。
|
||||
> - 收敛后 `net_relisten_try` 调用点 **7 → 5**（pump + 显式消息 + 3 处消费者驱动）。
|
||||
|
||||
> ⚠ **如实记录的观测**：`task stall` 是**既有现象**（P1 基线同条件 53 条 vs P2a 32 条，
|
||||
> 未恶化）；uiTask 最坏单轮的历史最大值 P2a 偏高（1054 ms vs P1 172 ms），但 `uil`
|
||||
> （最近一次）为 10999 µs 即**当前正常**，判为一次性卡顿，**留待观察**。
|
||||
|
||||
**回滚点**：P0 纯注释可直接 revert；P1 若回归失败 revert 单提交即可（④ 仍在，退回到"端口活着但慢消费者可能卡死"的已知状态）；P2a 独立成提交（`7cb5af0`），revert 后回到"对账③④ 兜底 + 12 所有者"的 P1 状态；P2b 未做。
|
||||
|
||||
Reference in New Issue
Block a user