三条可以搬走的并发取消经验

2026-08-09

写并发的人迟早都会碰到同一类需求：一个任务正在往外流数据，中途来了个新指令，得把旧的停掉。停掉本身不难，难的是停掉之后那些已经在路上的数据怎么办——它们可能还在队列里、还在另一个线程的 for 循环里、还在等一个永远不会来的结束信号。

speech-to-speech 的打断（barge-in）处理是这类问题的一个完整样本：用户在助手正播音频时开口说话，服务端要把当前响应干净地掐掉。它的 README 在 Interruption Handling 一节里把机制写得相当细，而且明确总结了三条可迁移的工程经验。这三条跟语音其实没什么关系，值得单独拿出来讲。

先把边界说清楚：下面的机制描述全部来自该仓库 src/speech_to_speech/api/openai_realtime/README.md 的原文与 cancel_scope.py 的构成说明。我们没有安装、部署或调用过这个服务，也没有触发过一次打断，所以不会有任何关于「打断快不快」「会不会截断半个字」的描述——那些得跑起来才有资格说。

经验一：用单调递增的世代号取消，别用「取消标志 + 时间窗」

它替掉了什么

README 说得很直白：CancelScope 是用来替换旧的双信号模式的。旧模式是两样东西并存——一个叫 cancel_response 的 Event，加上一个叫 discard_stale_output 的布尔值。新写法把这两样收进一个对象，由它统一管理。

对象里第一样东西是世代计数器 cancel_scope.generation。用法是这样的：

流水线线程（LLM、TTS）在每个响应开始时捕获当前世代，记成 gen；
在每个流式 token 上检查一次 cancel_scope.is_stale(gen)；
调用 cancel() 时世代递增，所有更早的世代立刻变成过期。

原文对这个设计给的评价是一句很短的话：no timing games required——不需要玩时序把戏。

为什么这句评价是重点

用布尔标志做取消，麻烦不在「怎么置位」，在「置位之后什么时候清掉」。清早了，还在路上的旧数据没被拦住；清晚了，新任务的输出被误伤。于是就得引入时间窗、引入「等一小会儿再清」，而这个「一小会儿」永远调不准——它取决于机器负载、模型吐词速度、队列深度，全是运行时才知道的量。

世代号把这个问题从时间维度换到了身份维度。不再问「这条数据是不是来晚了」，而是问「这条数据属于哪一轮」。轮次是个离散的、单调的、任何时刻都能精确比较的量，不需要估计任何延迟。

判断依据：你的系统要不要上这个

这套东西不是白来的，它要求每个产出物都能带上归属标签。所以先看三个问题：

你的输出是流式的吗？ 如果一个任务只在结束时返回一个整包结果，取消就是「丢掉这一个包」，一个标志足够了，别过度设计。
取消可能连续发生吗？ 一轮还没收尾第二轮就来了——这是世代号的主场，也是布尔标志最容易出错的地方。
产出物能不能盖章？ 在 speech-to-speech 里，AudioOutput 块和 AssistantTextEvent 都带一个 cancel_generation 字段，由产出它的 handler 盖上。如果你的数据结构里塞不进这么一个字段，得先解决这件事。

三个都是「是」，那基本就该照搬了。

经验二：冲队列的时候，必须有一份保留清单

机制原文

打断流程走到取消那一步时，send loop 做的事情是：调 cancel_scope.cancel()（世代递增、开启丢弃），清 response_pending，然后抽干两个队列。注意抽干不是全清：

队列	抽干时保留什么
`output_queue`	保留 `__RESPONSE_DONE__` 哨兵
`text_output_queue`	保留用户侧事件：`speech_stopped`、直接音频完成、部分/完整转写、token 用量

最后清 response_playing。

这份清单是怎么划出来的

看一眼保留项的共性就明白了：它们都不是助手这一轮的产物。

用户说了什么、说完没有、用了多少 token——这些是既成事实，是这次会话真实发生过的事。助手那一轮被取消了，不代表用户没说过话。把它们跟助手的音频块一起冲掉，丢的不是「过期输出」，是记录。转写没了，上下文就断了；用量没了，账就对不上了。

__RESPONSE_DONE__ 哨兵留着是另一个道理，它是控制信号不是数据。后面第三条会讲到，丢弃守卫的清除就指望它。把控制信号当数据一起冲掉，等于把自己的退路砍了。

判断依据：怎么给自己的队列列清单

拿一个问题挨个过每种消息类型：这条消息，如果丢了，是「少了一段没人要的输出」还是「系统忘了一件真发生过的事」？

前者随便冲。后者一律进保留清单。控制信号、外部输入的记录、计量数据，通常都属于后者。这个划法比「按消息类型硬编码」稳，因为将来加新消息类型时，问题还是那个问题。

经验三：当前世代的输出，永远放行

两个条件的丢弃判定

CancelScope 管的第二样东西是丢弃标志 cancel_scope.discarding，由 cancel() 置位，被异步的 _send_loop 检查，用来丢掉「在 cancel() 与 response_done() 之间抵达的、来自被取代世代」的输出。

具体判定在 _generation_is_discardable 里，README 给的是两个条件：一项被丢弃，要么是它的世代已过期，要么是 discarding 置位且该项不属于当前世代。

第二个条件末尾那半句是整段机制里最要紧的一句。它意味着：来自当前世代的输出永远放行，哪怕丢弃窗口还开着。

它防的是哪种 bug

README 专门为这条解释了一个场景：一个被取代的推测轮次，它的 TTS 从来没有发出过 __RESPONSE_DONE__ 哨兵。

顺着推一遍就知道有多凶险。discarding 有三条清除路径：

response_done(generation)——且仅当哨兵的世代与被丢弃的或当前的世代匹配时才清（来自无关旧世代的哨兵会被忽略）；
显式 response.create 触发的 new_response()；
会话认领/释放时的 reset()。

主路径是第一条，靠哨兵。可那个被取代的轮次压根没发哨兵，主路径就断了。如果丢弃判定只有「discarding 置位就丢」这一个条件，那么新响应生成的所有内容都会被这个永远关不上的窗口一路吃掉——服务还活着，队列在流转，日志里也不会有报错，用户那边就是没声音。

「当前世代永远放行」这一条，就是让新响应不依赖旧响应的收尾信号。旧的清除信号丢了是旧的事，新的一轮不该陪葬。

同一个思路在打断流程的最后一步还出现了一次，叫伪取消保护：如果没有活跃响应，就不会调用 cancel_scope.cancel()——避免在没有 __RESPONSE_DONE__ 来清除它的情况下，把丢弃守卫白白置位。客户端主动发来的 response.cancel 也遵守这条，只在有活跃响应时才真的取消。

判断依据：怎么在自己的代码里找同构问题

问三句话，任何一句答不上来就得回去看代码：

我这个「丢弃/暂停/降级」状态，清除它的信号由谁发？
那个发信号的东西，有没有可能死在发信号之前？
如果它真的没发，下一轮正常业务会不会被这个残留状态误伤？

第三问答「会」的，就必须补一条兜底——要么像这里一样按身份放行当前轮次，要么给状态本身加超时或版本号。别指望清除信号一定会到，这是分布式和并发系统里代价最高的一类乐观假设。

顺带一条：取消策略要可关掉

还有个容易被忽略的设计细节。打断不是无条件发生的，它有门控：只有当 SpeechStartedEvent.interrupt_response 标志被置位，并且会话配置允许（turn_detection.interrupt_response，经 RuntimeConfig.interrupt_response_enabled 读取，默认为 true）时，才真的执行取消。

关掉之后是什么行为？README 写得很清楚：响应期间的用户语音仍会被转写，但响应继续播放。

这个处理值得学。关掉的是「取消动作」，不是「感知能力」——输入照收照记，只是不再打断输出。很多系统在做开关时是一刀切的，把整条链路一起关掉，结果开关一关，连事后排查的数据都没有了。把「感知」和「动作」拆成两层，开关只作用在动作层，是更耐用的做法。

小结：三条经验的适用边界

回到最初那三条：

用单调递增的世代号做取消，比「取消标志 + 时间窗」健壮，不需要猜多久算晚；
冲队列时要有保留清单，用户侧事件（转写、用量、语音结束）不能跟着助手输出一起冲掉；
「当前世代永远放行」这条兜底，防的是「清除信号丢失导致新响应被静默吞掉」这类死锁式故障。

三条里第一条最容易搬，改造成本主要在给产出物加字段；第二条最容易漏，因为它平时不出事，出事的时候是数据不一致而不是崩溃；第三条最难自己想到，它属于那种「测试环境跑一万遍都不复现，上线第三天遇上一次」的边界条件——README 愿意把这个场景专门写出来，本身就说明它被踩过。

至于这套机制在真实负载下表现如何，我们没有依据，不做判断。上面所有内容都是代码结构与文档口径。

延伸阅读

本文依据 speech-to-speech 官方仓库（github.com/huggingface/speech-to-speech）的 README、 src/speech_to_speech/arguments_classes/ 下的参数定义与 Realtime Engine 架构文档整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装、部署或调用过该服务，文中毫秒值均为参数默认值而非实测延迟。参数与默认值随版本变动，请以 speech-to-speech serve -h 的实际输出为准。