realAaronWu opened a new issue, #436: URL: https://github.com/apache/paimon-cpp/issues/436
## 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
