|
|
cb32032f76
|
feat(scheduler)!: 中断/排队两类别模型 + 插件声明 L1-L3、L4 内核独占
用户澄清推翻了早期设计的三处前提，本提交按新模型重做调度核心（行为有意变化）：
1) 类别由注入 API 决定，与通道名无关
- InjectInterrupt* -> TaskInterrupt（带级别，可被严格更高级中断打断）
- InjectText*/InjectInputSync*/内核自循环 -> TaskQueued（无级别，可被任何中断打断）
- 删除按通道名推断的 taskLevel()：qq 走 InjectInterruptTextOpts，本就是中断
2) 级别只属于中断
- 插件在 InjectOptions.Priority 声明 L1-L3（空/非法降级 L1，声明 L4 夹到 L3）
- L4 内核独占：新增 raiseKernelInterrupt（panic / selfip）；requestKernelPreempt 不夹取
- panic 现在产生一条带 kernel 标记的 L4 中断；L4 自身 panic 不再产生新 L4（防自我放大）
3) 选择结构：四容器固定次序，删除统一比较器
- immediate（抢占者立即运行）-> 中断队列 L4..L1 -> 栈顶(与队头比级别) -> 排队 FIFO
- 删除 pickTaskIndex/taskBefore 与“同级 pending 优先”补丁（根因是抢占者进了队列）
- 中断栈上界改为结构推论 = 4（= 中断级数）；删除“超限转 pendingInterrupts”降级
公开 SDK（feature 分支有意新增，纯追加）：InjectOptions.Priority + PriorityL1/2/3；
内核 io / proc 桥 / 插件模板同步透传。
设计稿 §2/§3/§4.1/§6.3/§9/§11/§12/§13/§15 按新模型重写。
验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿；
e2e（抢占-挂起-恢复）+ 压力（200 排队 + 50 中断，L1/L2/L3 轮转）通过。
|
2026-09-13 07:00:51 +08:00 |
|
|
|
86a702b3b0
|
fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转
用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。
我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。
改动：
- suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**；
栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增，
且“后被打断的先恢复”才是栈语义。取出即弹栈。
- 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务
会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务
（入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。
现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。
- 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack
- 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 +
pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步
测试新增 scheduler_stack_test.go 3 项：
- 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A）
- 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现）
- 嵌套下的深度上限
验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 06:30:23 +08:00 |
|
|
|
f11de37bf2
|
feat(scheduler): M7 可观测性 + 压力测试 + 端到端测试
设计依据 docs/zh/input-scheduler-design.md §11.5（O1/O2）、§11.6（E1/E2）。
- 可观测性：KernelStatus 新增 Scheduler 段（running/三集合深度/计数/
深度上限），由 GetKernelStatus 从 DumpScheduler 原子快照填充；
新增 events.EventScheduler，挂起/恢复各发一条（action/task/level）
- TaskKind.String() 便于日志与状态输出
- 新增 scheduler_e2e_test.go 3 项：
· 压力：200 排队输入 + 50 中断全部经真实 loop 执行，结束时三集合排空、
LLM 调用数精确等于输入数、无 Rejected
· 可观测性：挂起/恢复事件齐备，状态快照计数一致
· 端到端：完整启动 schedulerLoop+interceptLoop，经真实 channel 投递
L1 任务与 L4 中断，验证「LLM 流式中断 → 挂起 → 中断先完成 → 原任务恢复」
整条链路（LLM 调用数 = 丢弃1+中断1+恢复1+常规1）
- 验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 00:45:28 +08:00 |
|
