From dbca624a54c9a94ebbe56d69f152246f85f00d20 Mon Sep 17 00:00:00 2001 From: Wanderingss <1624155937@qq.com> Date: Mon, 12 Oct 2026 14:11:44 +0800 Subject: [PATCH] =?UTF-8?q?docs(net):=20N-32=20P2a=20=E8=90=BD=E5=9C=B0?= =?UTF-8?q?=E8=AE=B0=E5=BD=95=20+=20=E4=BF=AE=E6=AD=A3=E8=AE=BE=E8=AE=A1?= =?UTF-8?q?=E6=96=87=E6=A1=A3=E7=9A=84=20P2=20=E5=8E=9F=E8=AE=A1=E5=88=92?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §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 不为此动热路径。 --- .../网络Socket监听生命周期设计说明.md | 65 ++++++++++++++----- 1 file changed, 48 insertions(+), 17 deletions(-) diff --git a/docs/子系统设计/网络Socket监听生命周期设计说明.md b/docs/子系统设计/网络Socket监听生命周期设计说明.md index 9855bad0..c5f621f9 100644 --- a/docs/子系统设计/网络Socket监听生命周期设计说明.md +++ b/docs/子系统设计/网络Socket监听生命周期设计说明.md @@ -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 未做。