You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor: use a dedicated ThreadPool instead of std::async for parallel deletes
Addresses review feedback on apache#649: std::async spins up a fresh std::thread per
DeleteFiles call (and per worker), which thrashes thread creation when
CleanFiles invokes DeleteFiles 3-4 times in a row. Replace with a per-strategy
ThreadPool that owns its workers for the lifetime of the strategy.
- New util/thread_pool_internal.h / .cc: minimal worker pool with eager thread
start, mutex+cv task queue, Submit returning a future<void>, and a RunAndWait
fan-out helper for span-of-items workloads. Drained on destruction.
- FileCleanupStrategy now holds a ThreadPool sized once at construction
(min(8, hardware_concurrency)). DeleteFiles short-circuits empty/single-item
batches and otherwise delegates to pool_.RunAndWait. The pool member is
declared last so workers are joined before file_io_ and delete_func_ are
destroyed.
- Drops the RunInParallel free template, the per-call WorkerCount, and the
<future>/<span> includes in expire_snapshots.cc.
- Adds util_test::ThreadPoolTest covering ctor validation, single submit,
fan-out, empty no-op, observed concurrency, exception isolation, and dtor
drain.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments