fix(executor): avoid retaining a callback when lazy worker startup fails
維護者通常 3 天內回覆
評估
研究方向
The fault is in DefaultExecutor::Add in executor.cpp, which enqueues the callback before lazy worker startup. Read that function and the lazy-startup path under the mutex, and note that status.cpp is compiled alongside it in the reproduction. Done means a failed startup leaves no retained callback, and a regression test injects allocation failures and shows later submissions do not run the failed callback. PR #437 already targets this, so review or coordinate there first.
由索引模型根據 Issue 內容生成。
描述
Problem
DefaultExecutor::Add queues its callback before reserving/starting lazy worker threads. If worker-vector allocation or thread startup throws, Add reports failure but retains that invocation's callback. A later successful submission can execute it. Callers therefore cannot assume that an escaping submission error means their callback was not accepted.
Actual-source reproduction
Base: 242decffdfdefef01dcd0e52e48c9a1e69792479 (main).
Linux x86_64, GCC 15.3, C++17. A standalone executable compiles the unmodified executor.cpp and status.cpp, with submitting-thread-only scalar-new injection. Executor, callables, promises, and futures are prepared before injection. Faults are disarmed before recovery and shutdown.
For a one-worker executor, observe allocations during the actual first Add, then inject each observed ordinal on a fresh executor. Catch bad_alloc, submit a recovery marker, wait for it on that same single-worker FIFO, and join the executor:
ordinal=1 fired=1 caught=1 observed=1 recovered=1 failed_callback_runs=1
ordinal=2 fired=1 caught=1 observed=2 recovered=1 failed_callback_runs=1
allocations=2 retained=2
The program exits 1 for callback retention, not a crash or timeout. This is executor CPU evidence, not a full native planner reproduction or GPU execution.
Proposed narrow fix and acceptance
- Complete lazy worker startup under the existing mutex before enqueueing the current callback.
- Preserve empty/stopped behavior and existing successful scheduling.
- Test real production-object allocation failures, active injection, successful recovery, partial startup, queue growth, and normal subsequent cleanup.
- Keep callable ownership/capture lifetimes alive through cleanup in the regression itself.
- Partial worker startup may leave idle workers; this fix need not restore configured capacity, but must not retain the failed invocation and must permit normal recovery/join.
This is a prerequisite ownership contract related to #435. It does not implement or close that feature: query cancellation, task draining, planning budgets, custom executor contracts, and allocation-failure safety of ShutdownNow remain separate.
- 主要語言
- C++
- 星號
- 68
- 分支
- 34
- 平均合併
- 4 天 37 分鐘
- 30 天內合併 PR
- 35
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
apache/paimon-cpp 的其他 Issue
-
[Feature] Support File Index V2 and streaming index writes可能已有人在做 @zjw1111 於 1 天前認領。 未關閉enhancement
難度 4/5 3-5 天 新手友好度 25/100
apache/paimon-cpp#445 ·
維護者通常 3 天內回覆
-
難度 5/5 一週以上 新手友好度 8/100
apache/paimon-cpp#435 · 2 則留言 ·
維護者通常 3 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 35/100
apache/paimon-cpp#410 ·
維護者通常 3 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 25/100
apache/paimon-cpp#409 ·
維護者通常 3 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 35/100
apache/paimon-cpp#408 ·
維護者通常 3 天內回覆
查看 apache/paimon-cpp 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
category:port-update
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 2 天內回覆
-
(S1 - Need confirmation)
難度 2/5 1-3 小時 新手友好度 65/100
CleverRaven/Cataclysm-DDA#89194 ·
維護者通常 1 天內回覆
-
reproduced
難度 1/5 1 小時以內 新手友好度 67/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆