Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

fix(executor): avoid retaining a callback when lazy worker startup fails

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

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

@realAaronWu がすでに取り組んでいます。

2026年10月16日 から。

  • #437 @realAaronWu による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
15/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
cpp
領域
backend

調査の方向性

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
平均マージ
3日 18時間
マージ済み PR（30日）
44

環境構築

はじめの一歩

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

apache/paimon-cpp のほかの issue

apache/paimon-cpp の issue をすべて見る

似ている issue

C++ の issue をもっと見る

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

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