libutil: don't make ThreadPool work items wait for process() - #718

Motivation

ThreadPool::enqueue() counts the thread that will later call process() as a worker, even before that thread has called process(). It starts a new worker only when pending > workers + 1, so before process():

• a single item enqueued into an idle pool doesn't run at all;
• in general, only K−1 of K pending items run.

The header describes process() as "Execute work items until the queue is empty", and nothing in the API says enqueued work is held back until then. A caller that enqueues work and waits for it some other way (a future, a condition variable, an in-flight counter) before calling process() hangs.

As far as we can tell, no in-tree caller hits this today. Every one either calls process() right after enqueueing, or keeps enqueueing so a second item soon starts a worker. We ran into it while working on GC deletion in background threads (a follow-up we plan to send), which waits for in-flight deletions before draining the pool. There, nix-store --gc --max-freed X hung whenever the first dead path was already larger than X.

Implementation

Count the calling thread only once process() has started (state->draining, already set by process() under the same lock):

auto busyThreads = state->workers.size() + (state->draining ? 1 : 0);
if (state->pending.size() > busyThreads && state->workers.size() + 1 < maxThreads)

• After process() has started: spawning is identical to before, so all existing fan-out is unchanged.
• Thread cap: unchanged. workers.size() + 1 < maxThreads still reserves the caller's slot, and ThreadPool(1) still runs everything on the caller inside process().
• Exceptions: exceptions from items that ran before process() are still rethrown by process().

Context

New unit test ThreadPool.executesWorkBeforeProcess enqueues one item into a ThreadPool(2) and waits for it before calling process(). On main the item never starts, so the test fails when its wait times out; with this change it passes.

🤖 Claude