P11 · WAITING_FOR_CHUNK：停靠与归还

例 1 见逐步图。

例 2：同时归还按 arrival 排序：add k(5)、m(3)、n(4)（都 needs_chunk）→ schedule() → []（三个都停靠，load_async 记录 ["k","m","n"]）→ 三个 chunk 同时到达 → schedule() → ["m", "n", "k"]。

例 3：上游抛异常时 finally 仍归还：

class Exploding(BaseScheduler):
    def schedule(self):
        src.ready.add("z")            # z 的 chunk 恰好在上游调度期间到达
        raise RuntimeError("boom")

s = ChunkAwareScheduler(Exploding(), src)
s.add(Req("z", 0, needs_chunk=True)); s.add(Req("y", 1))
s.schedule()       # RuntimeError("boom") 原样抛出
# 之后：base.waiting == [y(WAITING), z(WAITING)]，parked == {}，load_async 记录 ["z"]

z 归还时 append 到 waiting 末尾，所以排在 y 之后；异常没被吞掉。

关键问题

1. BaseScheduler 一看到 WAITING_FOR_CHUNK 就断言失败。“停靠”只改 status 够不够？请求此时应该在哪个容器里？
2. 同一请求连续 3 次 schedule() 都没就绪，load_async 应调用几次？归还后又没就绪呢？什么机制天然保证“每次停靠一次”？
3. running 中的请求被停靠时，previous status 是什么？归还时一律写 "WAITING" 的后果？
4. 为什么 (a) 先归还再 (b) 停靠？去掉 (a) 只靠上一轮的 (d)，会晚几轮被调度？
5. 在 (d) 中归还的请求，本轮 base.schedule() 的返回值里有它吗？
6. “按 arrival order 归还”的 arrival 指什么？
7. abort(id) 之后 is_ready(id) 仍可能 True，什么保证它不会被归还？它可能藏在哪几个地方？

细节

• parked[id] = (req, origin, previous_status)；origin 用什么表示由你决定（如 "waiting" / "running"）。
• BaseScheduler：返回 running 的 id + waiting 的 id，然后把 waiting 全部挪进 running 并设为 RUNNING——它从不改 running 中请求的 status，恢复 status 的责任完全在你这层。
• 只有 needs_chunk=True 的请求才会被停靠；is_ready 可以 True → False → True 反复变化。
• 归还放回 origin 队列末尾（waiting 是 deque，running 是 list）。

• 拆两个私有 helper：_restore_ready()（扫描 parked，把就绪的按 arrival 放回来源队列）和 _park_not_ready()（扫描两个队列，把 needs_chunk 且未就绪的移进 parked）。schedule() 就只剩四行：restore → park → try: return base.schedule() → finally: restore。
• load_async 去重：被停靠的请求已经不在队列里，(b) 下一轮看不到它，“停靠的那一刻调一次”天然满足“每次停靠一次”。想更保险可维护“已请求加载”集合，但要在归还/abort 时清掉。
• 归还顺序：先收集所有 is_ready 的条目，按 req.arrival 排序，再逐个删除、恢复 status、append。
• abort 的三个藏身处：parked、base.waiting、base.running 都要查并移除，状态可设为 ABORTED。

abort 的追踪（add a(0)、b(1, needs_chunk)、c(2)；b 没就绪）：