)
看完代码我明白为什么尾巴老清不掉了 ——根子不是没修到位而是前几轮一直在 调赌局参数没人敢把赌局本身拆了。逐条跟你议尾巴 1pid 文件未落地W-12/W-14 残留—— 这是最大的一条也是一直留尾巴的元凶看现在用例的结构test_agent_tools_light.py:580-603它调run_command(父脚本, timeout1.5)然后回头轮询 pid 文件 3s 等孙 PID。问题是满负载 10 核打满时父脚本自己双层 launcher bootstrap都要跑 1-2s它还没来得及Popen(孙) 写 pid 文件1.5s 就到了run_command 把父脚本杀了 ——pid 文件永远不会出现测试判失败。也就是说这个用例同时在赌两件事① root 在 1.5s 内 bootstrap 完② 父脚本在被杀前 spawn 出孙。前几轮 R90/R91/R92 干的全是调这些赌注参数0.8→1.5、窗口 3→6、stdout→pid 文件赌注本身没动。彻底解法要你拍板把 超时触发 和 杀树正确性 解耦 —— 测试自己 Popen root轮询等 pid 文件出现确认孙真的起来了再去调被测的杀树函数杀 root断言整树死。这样测的就是 杀树能不能杀掉一棵已经建好的树不再赌 CPU 调度。run_command 超时能不能自动杀树 本来就有另一个用例test_限时运行进程_超时硬杀挂起命令在测不该捆在一起。前几轮红线 不许改用例 我理解是怕放水但这次不是放水 —— 断言语义一字不改孙仍按 PID 判死、marker 仍不能出现只是把触发时机从 赌 1.5s 改成 等树真建好。这条不拆R93 还会留尾巴。尾巴 2本机满负载方差大根子是硬的这台 E5-2643 v2 只有 10 核-n auto10 worker 正好打满而 Windows 杀树用例是 win32-onlyFreeBSD 帮不上忙。run1 23min 4 条红 vs run2 36min 13 条红纯属当时机器上还开着多少东西。两个动作能收敛① R93 实测固定 worker 数留 2-4 核给系统比如-n 6跑 2-3 轮全量看红的数量是否稳定收敛到台账那几条② 与其等重载冒几条再补登不如主动在高负载下把所有 隔离转绿 的负载敏感用例一次性补登台账judge 覆盖全了就不再误报。尾巴 30.82import 进程解析到壳刚看了stdlib/进程.light—— 它就是个 16 行的导出 xxx声明壳真身是stdlib/进程.py。子集跑时预热不足import 命中了没解析到真身的壳。我的判断这不是产品缺陷是 人为切子集跑 pytest 这个使用方式本身不被支持—— 真实门禁是全量单进程3/3 绿。去修 light 的模块加载机制要动语法核心风险和收益完全不成比例。R93 应该做的是花半小时确认壳和真身的依赖关系壳是不是冗余、能不能让壳直接 re-export 真身能一行合掉就合合不掉就明确登记 切子集独立跑不支持把它结案而不是继续 观察。我的建议R93 就三条每条都有明确终点不再留 观察项表格路干什么终点怎么算清了A重写杀树两用例解耦超时触发与杀树正确性自己 Popen root → 等 pid ready → 调杀树 → 断言整树死类级-n auto连跑 15 轮 0 假红不再是 观察是 15 轮全绿B本机门禁 worker 数固化实验 负载敏感用例一次性补登台账固定 worker 数跑 3 轮全量judge 新增红稳定 0台账覆盖本轮所有隔离转绿项C进程.light壳真身依赖查清能合就合、不能合就登记边界要么壳消除import 不再依赖预热要么写死 切子集不支持 并提交结论需要你拍一个板A 路这个 重写杀树用例结构跟前几轮 不许改用例 的红线是冲突的—— 你认可以 解耦触发时机、不削弱断言 为标准授权改它吗认了我就按这个写 R93 分发书。后来终于到了R98轮,把问题算基本清理干净了!也就是其实主要是由各红线,导致一直在隔靴搔痒,没有根本性的解决问题.从R93开始,突破红线,问题很快彻底解决了!
咱们开发怎么老留尾巴啊？ 就不能彻底解决吗？ 这样，咱把留给 R93 的尾巴细细讨论一下，争取 R93 不再留尾巴！(光明项目一直拖拖拉拉有问题,都整到93轮了)
看完代码我明白为什么尾巴老清不掉了 ——根子不是没修到位而是前几轮一直在 调赌局参数没人敢把赌局本身拆了。逐条跟你议尾巴 1pid 文件未落地W-12/W-14 残留—— 这是最大的一条也是一直留尾巴的元凶看现在用例的结构test_agent_tools_light.py:580-603它调run_command(父脚本, timeout1.5)然后回头轮询 pid 文件 3s 等孙 PID。问题是满负载 10 核打满时父脚本自己双层 launcher bootstrap都要跑 1-2s它还没来得及Popen(孙) 写 pid 文件1.5s 就到了run_command 把父脚本杀了 ——pid 文件永远不会出现测试判失败。也就是说这个用例同时在赌两件事① root 在 1.5s 内 bootstrap 完② 父脚本在被杀前 spawn 出孙。前几轮 R90/R91/R92 干的全是调这些赌注参数0.8→1.5、窗口 3→6、stdout→pid 文件赌注本身没动。彻底解法要你拍板把 超时触发 和 杀树正确性 解耦 —— 测试自己 Popen root轮询等 pid 文件出现确认孙真的起来了再去调被测的杀树函数杀 root断言整树死。这样测的就是 杀树能不能杀掉一棵已经建好的树不再赌 CPU 调度。run_command 超时能不能自动杀树 本来就有另一个用例test_限时运行进程_超时硬杀挂起命令在测不该捆在一起。前几轮红线 不许改用例 我理解是怕放水但这次不是放水 —— 断言语义一字不改孙仍按 PID 判死、marker 仍不能出现只是把触发时机从 赌 1.5s 改成 等树真建好。这条不拆R93 还会留尾巴。尾巴 2本机满负载方差大根子是硬的这台 E5-2643 v2 只有 10 核-n auto10 worker 正好打满而 Windows 杀树用例是 win32-onlyFreeBSD 帮不上忙。run1 23min 4 条红 vs run2 36min 13 条红纯属当时机器上还开着多少东西。两个动作能收敛① R93 实测固定 worker 数留 2-4 核给系统比如-n 6跑 2-3 轮全量看红的数量是否稳定收敛到台账那几条② 与其等重载冒几条再补登不如主动在高负载下把所有 隔离转绿 的负载敏感用例一次性补登台账judge 覆盖全了就不再误报。尾巴 30.82import 进程解析到壳刚看了stdlib/进程.light—— 它就是个 16 行的导出 xxx声明壳真身是stdlib/进程.py。子集跑时预热不足import 命中了没解析到真身的壳。我的判断这不是产品缺陷是 人为切子集跑 pytest 这个使用方式本身不被支持—— 真实门禁是全量单进程3/3 绿。去修 light 的模块加载机制要动语法核心风险和收益完全不成比例。R93 应该做的是花半小时确认壳和真身的依赖关系壳是不是冗余、能不能让壳直接 re-export 真身能一行合掉就合合不掉就明确登记 切子集独立跑不支持把它结案而不是继续 观察。我的建议R93 就三条每条都有明确终点不再留 观察项表格路干什么终点怎么算清了A重写杀树两用例解耦超时触发与杀树正确性自己 Popen root → 等 pid ready → 调杀树 → 断言整树死类级-n auto连跑 15 轮 0 假红不再是 观察是 15 轮全绿B本机门禁 worker 数固化实验 负载敏感用例一次性补登台账固定 worker 数跑 3 轮全量judge 新增红稳定 0台账覆盖本轮所有隔离转绿项C进程.light壳真身依赖查清能合就合、不能合就登记边界要么壳消除import 不再依赖预热要么写死 切子集不支持 并提交结论需要你拍一个板A 路这个 重写杀树用例结构跟前几轮 不许改用例 的红线是冲突的—— 你认可以 解耦触发时机、不削弱断言 为标准授权改它吗认了我就按这个写 R93 分发书。后来终于到了R98轮,把问题算基本清理干净了!也就是其实主要是由各红线,导致一直在隔靴搔痒,没有根本性的解决问题.从R93开始,突破红线,问题很快彻底解决了!
