Function cpu_count 

pub fn cpu_count() -> i32

C epicsThreadGetCPUs() (osdThread.c), the live processor count.

Post-pin forward-port: this tracks epics-base HEAD, not R7.0.10. At the pin (osdThread.c:1123-1137) the function is sysconf of _SC_NPROCESSORS_ONLN, then _SC_NPROCESSORS_CONF, then a hardcoded 1 — none of which consults the calling thread’s CPU affinity mask, so a C IOC pinned to 2 of 64 processors still sizes its callback pool for 64. 556de06ff (“avoid overreporting available CPUs”, 2026-02-06, branch 7.0, in no tag) puts a sched_getaffinity + CPU_COUNT arm ahead of both sysconf calls. std::thread::available_parallelism is that behaviour, so this has been carrying the fix rather than the pin. Deliberately kept — reverting onto a number upstream itself calls overreporting buys no parity worth having — and named here because until now it was silent.

One divergence beyond that forward-port, stated rather than folded into it: available_parallelism also clamps to the cgroup CPU quota, which 556de06ff does not. In a container limited to 2 CPUs with no affinity mask set this returns 2 where even post-556de06ff C returns the host count. Same direction as the upstream fix, so it stays.

Distinct from parallel_threads_default, which is a settable knob merely SEEDED from this. callbackParallelThreads reads the two on different arms — a negative count is relative to the processor count, a zero count means the knob (callback.c:167-170) — so collapsing them into one accessor makes var callbackParallelThreadsDefault N silently move the negative arm too.