num_cpus

num_cpus is a focused Rust utility crate that answers one question: how many CPUs does the current machine (or container) have available? It exposes num_cpus::get() for logical core count and num_cpus::get_physical() for physical core count, with platform-specific implementations for Linux, macOS, Windows, BSD variants, and other Unix-likes, including cgroup-aware detection so containerized workloads report the CPU quota they’re actually allowed to use rather than the host machine’s full core count.

Despite its narrow scope, num_cpus is one of the most widely depended-upon crates in the Rust ecosystem (500M+ total downloads) because it’s the standard way for thread pools, async runtimes, and parallel-processing libraries to size themselves appropriately without hand-rolling platform-specific CPU detection.

What You Get

• num_cpus::get() returning the number of logical CPUs available to the current process
• num_cpus::get_physical() returning the number of physical CPU cores, distinct from logical/hyperthreaded cores
• Cgroup v1/v2-aware detection so containerized processes report their CPU quota, not the host’s full core count
• Platform-specific implementations covering Linux, macOS, Windows, and various BSD/Unix variants
• hermit-abi support for the Hermit unikernel target

Common Use Cases

• Sizing a thread pool (e.g. Rayon, Tokio) to match the number of available CPU cores
• Configuring worker/connection counts in servers based on available parallelism
• Detecting the actual CPU quota inside a Docker/Kubernetes container rather than the host’s total cores
• Build scripts or CLI tools that parallelize work based on detected core count
• Any library needing a sensible default level of parallelism without requiring user configuration

Under The Hood

Architecture - The entire crate is implemented in a single src/lib.rs (491 lines) using conditional compilation (#[cfg(...)]) to select the correct core-counting strategy per target OS: reading /proc/cpuinfo and cgroup CPU quota files on Linux, calling sysctl via libc on macOS/BSD, and using the Windows API on Windows. The fixtures/cgroups and fixtures/cgroups2 directories hold sample cgroup filesystem layouts used to test the container-aware detection logic against both cgroup v1 and v2 formats.

Tech Stack - Pure Rust with a single dependency, libc, gated to non-Windows targets via [target.'cfg(not(windows))'.dependencies], plus an optional hermit-abi dependency for the Hermit unikernel target. This minimal, platform-gated dependency tree is intentional given how many downstream crates depend on num_cpus transitively.

Code Quality - The crate includes 2 inline #[test] functions plus an examples/values.rs example demonstrating both get() and get_physical(), and ships dedicated cgroup fixture data specifically to test container-quota detection paths that are otherwise hard to exercise in CI. GitHub’s health signal shows low recent development activity and infrequent maintenance, which is typical and appropriate for a small, stable, feature-complete utility crate rather than a sign of an abandoned project — the core functionality (reading CPU counts) doesn’t need frequent changes.

API Design - The API is two functions: get() and get_physical(), both zero-argument and returning a plain usize. There’s no configuration, builder pattern, or error type to handle — a deliberate minimalism appropriate for a crate whose entire job is answering one simple platform query, though it does mean callers can’t easily override or mock the detected count for testing without wrapping it themselves.