热键 bridge 串行阻塞：一次慢 IO 就能让热键彻底失灵（已为此挖了三条旁路）

オープン
  • 何か問題がありますか？
#872 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
rust, tauri
領域
desktop, performance

調査の方向性

Read hotkey_bridge_loop and the async_runtime::block_on work it drives, then the three bypasses it spawned: the Esc channel (#853), the combo-cancel channel (#858), and HOTKEY_QUEUE_GRACE_MS / is_queued_chain_press. Read #468/#475 first, since they explain why Pressed/Released ordering must stay serial, and #871 for the current 5s timeouts. Done means latch/phase transitions still follow physical key order while begin_session / end_session leave the bridge thread, backed by tests that key-edge ordering is unchanged.

索引モデルが issue の本文から書いたものです。

説明

P3

现象

热键的按下 / 松开事件走一条串行 bridge 线程（hotkey_bridge_loop，async_runtime::block_on 逐个处理）。而这条线程上跑的是开麦克风、连 ASR、转写、LLM 润色这些慢活。

结果是：这条线程上任何一次慢 IO，都会让热键在此期间完全失去响应 —— 按下开不了录音，松开也停不了，且没有任何 UI 提示，用户只会认为「热键坏了」。

实测（macOS，StepFun 实时 ASR）：连续开会话时一次 WebSocket 建连没有返回，之后热键完全无响应，只能退出 app 重开。日志里 tap 线程仍在正常记录按键，只是没人处理：

07:20:14.201  [hotkey] 触发键与其他键组合按下 —— 撤销本次触发     ← tap 活着
07:20:15.985  [hotkey] 触发键与其他键组合按下 —— 撤销本次触发     ← tap 活着
                                                    ↑ 但没有任何 [coord] hotkey pressed

sample 确认 openless-hotkey-bridge 停在 __psynch_cvwait（block_on 等 future），主线程与 tap 线程都正常。

#871 给三个供应商的建连补了 5s 超时，把「永远死」降级成「死 5 秒」。但那是止血，不是修复。

这个结构已经反复付出代价

它不是一个假设中的隐患 —— 目前代码里至少有三处逻辑，存在的唯一理由就是绕开这条线程会堵：

  1. Esc 取消专用通道（#853）。转写 + 润色在 bridge 线程上同步跑，Esc 若与 Pressed/Released 同队列就只能排在后面，等流程结束才被取出，此时 phase 已回 Idle、cancel 变 no-op —— 用户按 Esc 毫无反应。修法是给 Esc 单开一条 Sender<()> + 专用消费线程。

  2. 组合键撤销专用通道（#858）。同一个病：撤销事件排在这次按下自己的 begin_session 后面，胶囊要等开麦跑完才消失（实测差 0.8~1s）。又单开一条通道。

  3. 「排队接力」判定（HOTKEY_QUEUE_GRACE_MS = 120，is_queued_chain_press）。转写期间的按下被缓在 channel 里，会话收尾后才取出；需要额外逻辑区分「刚才排队的那次按下」和「用户新按的」，以免与 #545 的冷却保护打架。

每加一条旁路，就多一组「两条通道之间谁先谁后」的竞态要考虑。#858 里已经为此加了回归测试（Released 抢先跑完时撤销仍须生效）。这是在给同一个病贴第 N 张膏药。

为什么不能简单地把串行撤掉

串行本身是 #468/#475 的解药：Pressed/Released 若并行执行，hotkey_trigger_held latch 的翻转顺序会乱（Windows 的 WH_KEYBOARD_LL 边沿间隔可到微秒级），表现为「录音停不下来」或「下次按键被静默吞掉」。代码注释里标为 P0。

所以这不是「删掉 block_on 就好」，而是要换一种方式同时满足：

  • 按键边沿的处理顺序必须严格跟随物理顺序；
  • 慢 IO（开麦 / 建连 / 转写 / 润色）不得占住边沿处理。

候选方向（列出来，不替维护者选）

  • A. 边沿处理与会话工作分离：bridge 只做纯同步的状态机迁移（latch、phase 判定），把 begin_session / end_session 派发到运行时，用 session id + 代次号丢弃过期结果。顺序由 bridge 保证，慢活不再占线程。
  • B. 保留串行，但给所有落在 bridge 上的 await 强制上限：本质是 #871 的推广，简单但治标；只要有人漏加一个超时就会复发。
  • C. 单一事件队列 + 优先级：把 Esc / 组合键撤销那些旁路收回同一条队列，用优先级而非独立通道，减少竞态面。不解决「慢活占线程」，但能止住旁路增殖。

各有代价，且都动到当初为修 #468/#475 而引入的部分，风险不低。

我的打算

暂不动手，等维护者定方向。这块是全仓库最容易出竞态的地方，我不想在方向未定时先改，那只会制造一处最难合并的分叉。

如果维护者认可某条路子，我可以按那个方向做，并先把按键顺序那部分单独抽出来补测试，确认改完顺序仍然正确再动线程。

相关：#853、#858、#871（均为绕开或止血），#468 / #475（串行的由来），#545（冷却保护，与排队接力互相牵扯）。

主要言語
Rust
スター
3.7k
フォーク
349
平均マージ
2日 14時間
マージ済み PR（30日）
97

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Open-Less/openless のほかの issue

Open-Less/openless の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。