fix(WeaselIPC, WeaselServer): 客戶端 IPC 改為有界等待，托盤刷新移至專用執行緒（#1909 後續） by Wujidadi · Pull Request #1914 · rime/weasel

Wujidadi · 2026-08-22T12:07:47Z

概要

補 #1909 的客戶端那一半，與已合併的 #1912 互補。

#1912 把托盤刷新移到伺服器訊息執行緒，斷開了「explorer 工作列執行緒等管線回應 ↔ WeaselServer 管線工作執行緒等 Shell_NotifyIcon」的死結環，解決了最常見的 7～8 秒凍結。
但 WeaselIPC 客戶端本身仍是無限等待：TSF 模組載入於每個宿主行程，焦點切換與按鍵的 IPC 往返都跑在宿主 UI 執行緒上，只要伺服器因任何原因停頓，宿主視窗就被一起拖死。
本 PR 讓跑在宿主執行緒上的客戶端 IPC 一律有上限，伺服器端呼叫路徑維持原行為。

現況問題（`WeaselIPC/PipeChannel.cpp`）

_Connect() 以 while (_Invalid(pipe = _TryConnect())) ::WaitNamedPipe(name, 500); 無限重試——伺服器忙到掛不出管線執行個體時，宿主 UI 執行緒永遠等下去。
_Receive()／_WritePipe() 用同步 ReadFile／WriteFile，無逾時；連上之後伺服器不回應即死等（WeaselIPC 客戶端在宿主程式 UI 執行緒上無限等待伺服器，切換視窗時造成卡頓或視窗凍結 7～8 秒 #1909 與 weasel.dll 导致应用进程卡死，附详细堆栈信息 #1878 的傾印都停在這裡的 WaitForSingleObject(hPipe, INFINITE)）。
_WritePipe() 內的 FlushFileBuffers 在具名管線上會等到對端讀走才返回，伺服器忙碌時成為額外阻塞點；request/response 模式已有同步點，此呼叫無必要。

#1912 之後仍會觸發上述等待的情境：

部署、SyncUserData、大型 userdb 寫入等使 g_api_mutex 長時間被持有。
RimeWithWeaselHandler::FocusIn → _UpdateUI() 仍在管線工作執行緒上呼叫 m_ui->Hide()／m_ui->Update()；後者在 ctx/status 改變時會走 WeaselPanel::Refresh() 的 SetWindowPos，而候選視窗屬伺服器訊息執行緒，跨執行緒 SetWindowPos／ShowWindow 是同步送訊息。若訊息執行緒此刻正在 Shell_NotifyIcon（內部 SendMessageTimeout 帶 SMTO_BLOCK，期間不處理送入訊息），原本的環仍可短暫成立。
第三方掛鉤（防毒）包覆管線 I/O 拉長處理時間。

修改內容

三個提交，可獨立審閱：

1. `WeaselIPC` 客戶端有界等待

全部收斂在 WeaselIPC，不動 TSF 端語義：

_Connect() 改為 fail-fast：一次連不上即丟 ERROR_PIPE_BUSY，由既有 _Ensure() 接住回傳失敗；移除 WaitNamedPipe 迴圈。
管線以 FILE_FLAG_OVERLAPPED 開啟；新增 _WaitIo() 對讀寫套 WaitForSingleObject 逾時，逾時即 CancelIoEx 視同斷線。ERROR_MORE_DATA 兩段式讀取語義保留。
移除 _WritePipe() 的 FlushFileBuffers。
_ConnectServerPipe() 配合改用 OVERLAPPED 的 ConnectNamedPipe（等待仍為 INFINITE），並修掉失敗路徑的控制代碼洩漏。
_WritePipe()／_Receive()／Transact() 新增 timeout_ms 參數，預設 INFINITE，伺服器端呼叫不受影響。
客戶端逾時依指令性質分兩級（WeaselClientImpl.cpp 的 _TimeoutForCommand()）：
- 組字／按鍵路徑（真實按鍵的 PROCESS_KEY_EVENT、COMMIT、選字、翻頁等）：kClientIoTimeoutMs，確保按鍵不因短暫忙碌被放行。
- 焦點／通知路徑（ECHO、FOCUS_IN／FOCUS_OUT、START_SESSION／END_SESSION、START_MAINTENANCE／END_MAINTENANCE、UPDATE_INPUT_POS、TRAY_COMMAND，以及 OnSetThreadFocus 送出的 keycode 0 焦點刷新探測）：kClientFocusTimeoutMs，漏掉一次下次事件自動補上。

失敗路徑：所有逾時／錯誤以 DWORD 例外丟出，由 ClientImpl::_SendMessage 既有的 catch (DWORD) 接住回 0，輸入法安靜降級（該次按鍵放行、下次自動重連），宿主程式不受影響。

2. `_Send()` 重連後改用新控制代碼

PipeChannel::_Send() 的 catch 區塊在 _Reconnect() 後仍以按值傳入的舊控制代碼重送，該次重送注定失敗；改為取 _GetPipeHandle() 重送。

3. 托盤刷新改於專用執行緒（#1912 的後續）

#1912 把 Shell_NotifyIcon 移到伺服器訊息執行緒，但訊息執行緒同時擁有候選視窗：管線工作執行緒在 FocusIn → _UpdateUI() 仍會對候選視窗做跨執行緒 ShowWindow／SetWindowPos，同步送訊息給訊息執行緒；而 Shell_NotifyIcon 內部以 SMTO_BLOCK 等工作列、期間不處理送入訊息。當工作列 UI 執行緒正在等管線回應時，環仍可能成立（只在焦點切換伴隨 UI 狀態改變時，窗口比原本窄）。

WeaselTrayIcon 改由專用執行緒套用刷新：RequestRefresh() 存快照並喚醒，RefreshThreadProc() 合併待處理請求後呼叫 Refresh()，DisableRefresh()／解構子停止並 join。Shell_NotifyIcon 可自任一執行緒呼叫，回呼訊息仍送至 hWnd 所屬的訊息執行緒。
移除因此無用的 WM_WEASEL_SERVICE_NOTIFY、ServerImpl::OnServiceNotifyMessage、Server::SetTrayRefreshCallback。
移除 _RefreshTrayIcon() 對 explorer.exe 延遲 100 ms 另開執行緒的「Dangerous, don't touch」繞道：回呼已不阻塞，對任何客戶端同步呼叫皆安全。

若維護者希望保留 #1912 的訊息執行緒結構，第 3 個提交可單獨拆出另議。

逾時值

目前提交的值為 kClientIoTimeoutMs = 500、kClientFocusTimeoutMs = 25，是在 #1909 的環境（Windows 11 25H2、0.17.4）實測肉眼無感且輸入正常的值。
這兩個常數開放討論：若偏好保守，可改為焦點 100 ms／按鍵 1000～2000 ms，或改成可由 weasel.yaml 設定；我可依回饋調整。

測試

Windows 11 25H2（build 26200）、x64 自建版，連續使用 2026-08-09 至 2026-08-22：多開視窗、快速點擊工作列切換，凍結消失；VS Code、Windows Terminal、檔案總管輸入正常；候選視窗、切換中英、部署通知行為不變。
與 fix(WeaselServer): avoid tray refresh blocking IPC pipe #1912 同時套用（合入 d73f629 後重建）亦正常。
未測：ARM64、Win32 宿主（32 位元程式載入 32 位元 weasel.dll）——程式碼路徑相同，但未在實機驗證。（我沒有這種實機😭）

Pull request overview

This PR follows up on #1909/#1912 by (1) making WeaselIPC client-side pipe operations bounded (so host-app UI threads don’t block indefinitely when WeaselServer is busy) and (2) moving tray refresh execution off the server message thread to further reduce deadlock risk involving Explorer/taskbar interactions.

Changes:

Add client-side IPC timeouts via overlapped pipe I/O and per-command timeout selection (focus vs keystroke paths).
Fix resend-after-reconnect to use the new pipe handle instead of the stale one.
Move tray icon refresh to a dedicated thread and remove the prior server-message-thread refresh callback/WM message path and the explorer-specific delayed workaround.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
WeaselServer/WeaselTrayIcon.h	Introduces dedicated tray refresh thread plumbing (thread member, API changes).
WeaselServer/WeaselTrayIcon.cpp	Implements coalesced refresh processing on a dedicated thread and shutdown/join behavior.
WeaselServer/WeaselServerApp.cpp	Removes server refresh callback wiring; uses direct `RequestRefresh()` + `DisableRefresh()`.
WeaselIPCServer/WeaselServerImpl.h	Removes `WM_WEASEL_SERVICE_NOTIFY` handler and tray refresh callback plumbing.
WeaselIPCServer/WeaselServerImpl.cpp	Removes tray refresh message handler and `Server::SetTrayRefreshCallback` implementation.
WeaselIPC/WeaselClientImpl.cpp	Adds `_TimeoutForCommand()` and applies bounded timeouts to client `Transact`.
WeaselIPC/PipeChannel.cpp	Implements overlapped connect/read/write + bounded wait/cancel behavior and server-side overlapped `ConnectNamedPipe`.
RimeWithWeasel/RimeWithWeasel.cpp	Removes the explorer-specific delayed refresh workaround (now safe to call synchronously).
include/WeaselIPC.h	Removes `WM_WEASEL_SERVICE_NOTIFY` and `Server::SetTrayRefreshCallback` from the public interface.
include/PipeChannel.h	Adds timeout constants and timeout-capable `Transact/_Send/_ReceiveResponse` API surface.

Suppressed comments (2)

WeaselIPC/PipeChannel.cpp:101

_WaitIo can block indefinitely after a timeout/WAIT_FAILED because it unconditionally calls WaitForSingleObject(INFINITE) after CancelIoEx without checking whether CancelIoEx actually succeeded (or why it failed). If CancelIoEx fails unexpectedly, the intended bounded-wait behavior can be lost. Handle CancelIoEx failure explicitly and preserve the original wait error when throwing.

  if (wait != WAIT_OBJECT_0) {
    ::CancelIoEx(pipe, &ov);
    ::WaitForSingleObject(ov.hEvent, INFINITE);
    _ThrowCode(wait == WAIT_TIMEOUT ? static_cast<DWORD>(ERROR_TIMEOUT)
                                    : ::GetLastError());

WeaselIPC/PipeChannel.cpp:177

In _ConnectServerPipe, the overlapped ConnectNamedPipe wait ignores the return value of WaitForSingleObject. If the wait fails (e.g., invalid event handle), the code proceeds to GetOverlappedResult and can report a confusing error. Check the wait result and fail/close the pipe handle immediately on WAIT_FAILED.

  if (!ok && err == ERROR_IO_PENDING) {
    ::WaitForSingleObject(op.ov.hEvent, INFINITE);
    DWORD n = 0;

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+struct OverlappedOp {
+  OVERLAPPED ov;
+  OverlappedOp() : ov() { ov.hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); }
+  ~OverlappedOp() {
+    if (ov.hEvent)
+      ::CloseHandle(ov.hEvent);
+  }
+};


-    state = m_pending_state;
-    m_refresh_pending = false;
-    m_refresh_in_progress = true;
+    Refresh(state);


- `OverlappedOp` 於 `CreateEvent` 失敗時立即拋出，避免後續以空事件等待。 - `_WaitIo()` 在 `CancelIoEx` 與第二次等待之前先保存逾時／失敗的原始錯誤碼，不再被後續呼叫覆寫；第二次等待仍為必要：`OVERLAPPED` 位於呼叫端堆疊，I/O 未完成前不得返回，`CancelIoEx` 唯一的失敗情境（`ERROR_NOT_FOUND`）代表 I/O 已完成、事件已觸發。 - `_ConnectServerPipe()` 檢查 `WaitForSingleObject` 結果，失敗即取消 I/O、關閉管線並拋出。 - `_Receive()` 失敗（含逾時）時關閉客戶端的管線連線：被放棄的回應否則會留在管線中，成為下一筆請求讀到的回應；下一次交易自動重連，伺服器端工作執行緒於讀寫失敗時自行收尾。

`Refresh()` 在托盤執行緒修改 `CSystemTray` 狀態（`m_tnd`、`m_bHidden` 等），而訊息執行緒仍會在工作列重建（`InstallIconPending()`）與托盤通知（`OnTrayNotification()`）時觸及同一組狀態。三個進入點一律持 `m_tray_mutex`；採 recursive mutex，因托盤選單的模態迴圈可能在持鎖期間派送工作列重建訊息。 `CSystemTray::InstallIconPending()` 改為 virtual 以便覆寫。

Wujidadi · 2026-08-22T12:24:30Z

已依 Copilot 的審查補了兩個提交（8d429d9、1a853c7）：

WeaselIPC/PipeChannel.cpp

OverlappedOp：CreateEvent 失敗即拋出。
_WaitIo()：在 CancelIoEx 之前先保存逾時／失敗的原始錯誤碼，不再被第二次等待覆寫。第二次 WaitForSingleObject(INFINITE) 保留：OVERLAPPED 位於呼叫端堆疊，I/O 未完成前不能返回；CancelIoEx 唯一會失敗的情境是 I/O 已完成（ERROR_NOT_FOUND），此時事件已觸發、等待立即返回，不會無限阻塞。
_ConnectServerPipe()：檢查 WaitForSingleObject 結果，失敗即取消 I/O、關閉管線並拋出。
另補一個審查未提、但我自查發現的問題：_Receive() 逾時後原本未關閉連線，被放棄的回應會留在管線裡成為下一筆請求的回應。現在 _Receive() 失敗即關閉客戶端連線，下一次交易自動重連；伺服器端 _ProcessPipeThread 本就在讀寫失敗時 _FinalizePipe。

WeaselServer/WeaselTrayIcon.*

Refresh()（托盤執行緒）、InstallIconPending()（工作列重建）、OnTrayNotification()（托盤通知）三個進入點一律持同一把 recursive mutex；CSystemTray::InstallIconPending() 改為 virtual 以便覆寫。
OnTrayNotification() 實際只讀 Create() 之後不再變動的欄位，加鎖主要是讓狀態存取規則單純。

- `OverlappedOp` 於 `CreateEvent` 失敗時立即拋出，避免後續以空事件等待。 - `_WaitIo()` 在 `CancelIoEx` 與第二次等待之前先保存逾時／失敗的原始錯誤碼，不再被後續呼叫覆寫；第二次等待仍為必要：`OVERLAPPED` 位於呼叫端堆疊，I/O 未完成前不得返回，`CancelIoEx` 唯一的失敗情境（`ERROR_NOT_FOUND`）代表 I/O 已完成、事件已觸發。 - `_ConnectServerPipe()` 檢查 `WaitForSingleObject` 結果，失敗即取消 I/O、關閉管線並拋出。 - `_Receive()` 失敗（含逾時）時關閉客戶端的管線連線：被放棄的回應否則會留在管線中，成為下一筆請求讀到的回應；下一次交易自動重連，伺服器端工作執行緒於讀寫失敗時自行收尾。 (cherry picked from commit 8d429d9)

- build.bat 的 fork 版號後綴進位 -wujidadi.4 - FORK-CHANGELOG 新增 0.17.4-wujidadi.4 節，記錄自 rime#1914 分支揀回的四筆修正 - appcast 與 testing-appcast 條目更新至 0.17.4-wujidadi.4

按用户指令恢复 GPU 优先/WARP 兜底（WEASEL_WARP=1 可选软渲染）： CPU 满载时渲染不与系统抢 CPU，全屏布局+阴影在 4K 下必须 GPU （对抗审查 rime#7 实锤该场景软渲染为每键整屏 CPU 光栅化）。服务器端已接受管道改阻塞读写：worker 线程可弃，无需每请求付 overlapped 事件跳转；客户端完整保留 overlapped+分级超时，rime#1914 防冻语义不变。审查确认无死锁/帧错位回归。对抗性审查（18 项）落地四项修复： - Present 改回 (0,0)：每帧等 vblank 最高 8ms 打字卡顿，TSF 进程内模式下卡的是宿主应用 UI 线程（rime#1） - _ReceiveSync 删短读分支：防旧版客户端消息被当正文吞掉造成帧错位（rime#10） - Initialize 先销毁旧保活会话：防部署后双初始化泄漏（rime#14） - Prewarm 应用待定尺寸 + 隐藏期钳位用待定尺寸（rime#2/rime#3） GPU 模式验证：p50 40µs、会话 3ms、切换 1ms、句柄 30k 键稳定；单测/parser 门全绿；墨菲压测（90k 键+并发+强杀客户端）全过。

fxliang · 2026-09-11T03:37:06Z

命名管道变成无名管道？

Wujidadi · 2026-09-11T04:33:19Z

命名管道变成无名管道？

不是，兩端仍然是具名管道。是指 _Connect(const wchar_t* name) 的 name 被拿掉嗎？

name 參數原本用在 WaitNamedPipe(name, 500) 的無限重試迴圈，
我改成：一次連不上，就拋 ERROR_PIPE_BUSY，由 _Ensure() 回傳失敗，參數已無用，故移除。
管道兩端還是 client 端的 _TryConnect() → CreateFile(pname, ...) 和 server 端的 CreateNamedPipe(pn, ...)，
但各自加上 FILE_FLAG_OVERLAPPED 旗標，讓讀寫可帶逾時。

Wujidadi added 3 commits August 22, 2026 18:37

Copilot AI lite review requested due to automatic review settings August 22, 2026 12:07

Copilot started reviewing on behalf of Wujidadi August 22, 2026 12:08 View session

Copilot AI reviewed Aug 22, 2026

View reviewed changes

Wujidadi added 2 commits August 22, 2026 20:21

LazyXuan mentioned this pull request Sep 11, 2026

fix(WeaselIPC): bound client pipe I/O with timeouts to prevent host UI hangs #1923

Closed

Navigation Menu

Uh oh!

fix(WeaselIPC, WeaselServer): 客戶端 IPC 改為有界等待，托盤刷新移至專用執行緒（#1909 後續） - #1914

fix(WeaselIPC, WeaselServer): 客戶端 IPC 改為有界等待，托盤刷新移至專用執行緒（#1909 後續）#1914
Wujidadi wants to merge 5 commits into
rime:masterfrom
Wujidadi:fix/ipc-bounded-wait

Wujidadi commented Aug 22, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Wujidadi commented Aug 22, 2026

Uh oh!

fxliang commented Sep 11, 2026

Uh oh!

Wujidadi commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Wujidadi commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

概要

現況問題（WeaselIPC/PipeChannel.cpp）

修改內容

1. WeaselIPC 客戶端有界等待

2. _Send() 重連後改用新控制代碼

3. 托盤刷新改於專用執行緒（#1912 的後續）

逾時值

測試

相關

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Wujidadi commented Aug 22, 2026

Uh oh!

fxliang commented Sep 11, 2026

Uh oh!

Wujidadi commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Wujidadi commented Aug 22, 2026 •

edited

Loading

現況問題（`WeaselIPC/PipeChannel.cpp`）

1. `WeaselIPC` 客戶端有界等待

2. `_Send()` 重連後改用新控制代碼