Inspect rayon pool is per-root, so a multi-root daemon runs N×8 inspect threads #202

start_dispatch_loop builds a rayon pool sized available_parallelism()/2 clamped to 8, with 8 MB stacks:

// inspect/dispatch.rs:22
rayon::ThreadPoolBuilder::new()
    .num_threads(default_pool_size())          // ncores/2, clamp(1,8)
    .thread_name(|index| format!("aft-inspect-{index}"))
    .stack_size(8 * 1024 * 1024)               // :31 — raised so the duplicates AST walker doesn't SIGABRT

That pool is owned by InspectManager, which is constructed inside AppContext (context.rs:1793) — and AppContext is per project root. So the pool count scales with bound roots rather than with the machine.

Observed

A aft --subc daemon on a 16-core box with 7+ roots bound over its lifetime:

Threads: 195
   88  aft-inspect-*      ← 11 pools × 8
   56  aft-executor-wo*
   24  aft-subc
   10  notify-rs inotify
    8  reqwest-internal
    6  aft-fs-lock-hea*

88 inspect threads at 8 MB of stack reservation each. The count plateaus at roughly (roots × 8) rather than growing per request — 195 → 197 over 90 s with inspect flat at 88 — so this is accumulation, not a leak.

Why it only shows up now

In standalone mode each session got its own short-lived worker process, so one pool existed at a time and died with the process. The daemon is the first thing that holds many roots in one address space for hours, which turns a per-root pool into a multiplier.

It also amplifies the allocator issue in #201: each allocating thread gets its own glibc arena, so thread count drives arena count directly.

Suggested direction

The inspect pool looks like a process-wide resource rather than a per-root one — the work is CPU-bound scanning, and default_pool_size() is already derived from machine parallelism, which only makes sense if there is one pool. A shared pool behind a OnceLock/LazyLock with per-root job routing would keep the current concurrency semantics while making the thread count machine-shaped again.

If per-root isolation is load-bearing for a reason I have not spotted (cancellation scoping, or the heavy_root_work_allowed gate), then sizing the pool by max(1, ncores/2/expected_roots) would at least bound the total — but a shared pool seems cleaner and the gate is already passed in per root.

Happy to send a PR if you want it in the shared-pool shape; I did not want to guess at the isolation requirement first.