feat(thread_aware): expose ThreadRegistry::with_hardware for SystemHardware injection

[sandersaares]

Promote ThreadRegistry::with_hardware to public API so consumers can inject a single shared many_cpus::SystemHardware instance instead of having every layer re-resolve SystemHardware::current(). SystemHardware is meant to be reused as a service, but the only public constructor (new / default) hid the injection path, leaving customers unable to supply their own.

ThreadRegistry::new keeps resolving SystemHardware::current() at the top of the chain and threads that one instance through, so simple call sites are unchanged. Added many_cpus::SystemHardware to the crate's allowed_external_types allowlist since it now appears in the public signature.

Also fixes a pre-existing boundary off-by-one: the asserts now permit exactly u16::MAX processors/memory regions, matching the documented 'more than u16::MAX' panic boundary. And the 'not enough processors available' panic now reports the requested vs available counts to make injection failures actionable.

This is the only place in the workspace that touches SystemHardware; no other crate constructs ThreadRegistry.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (542a32c) to head (e2623e1).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #535   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         343      343           
  Lines       26202    26208    +6     
=======================================
+ Hits        26202    26208    +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR makes ThreadRegistry::with_hardware a public API (behind the threads feature) so downstream consumers can inject and reuse a shared many_cpus::SystemHardware instead of repeatedly resolving SystemHardware::current() across layers.

Changes:

• Promotes ThreadRegistry::with_hardware from pub(crate) to pub and updates rustdoc to describe intended injection/reuse.
• Keeps ThreadRegistry::new behavior as a convenience wrapper that resolves SystemHardware::current().
• Adds many_cpus_impl::system_hardware::SystemHardware to cargo_check_external_types allowlist to account for the new public signature.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
crates/thread_aware/src/registry.rs	Exposes with_hardware publicly and adjusts docs for new/with_hardware.
crates/thread_aware/Cargo.toml	Allowlists SystemHardware’s defining path for public API external-type checks.

Comments suppressed due to low confidence (2)

crates/thread_aware/src/registry.rs:64

• The panic documentation says "more than u16::MAX processors or memory regions", but with_hardware currently asserts processors.len() < u16::MAX as usize and numa_nodes.len() < u16::MAX as usize, which also panics when the count is exactly u16::MAX. Update the docs to match the actual boundary (or adjust the checks).

    /// This will panic if there are not enough processors available when using `Manual` or if no processors are available when using `Auto` or `All`.
    /// If there are more than `u16::MAX` processors or memory regions.

crates/thread_aware/src/registry.rs:88

• Now that with_hardware is part of the public API, the panic message from this expect is customer-facing. It would be more actionable if it included the requested ProcessorCount value (e.g., which manual count was requested).

        let processors = match count {
            ProcessorCount::Auto | ProcessorCount::All => builder.take_all(),
            ProcessorCount::Manual(count) => builder.take(*count),
        }
        .expect("Not enough processors available");

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Vaiz]

Thing to consider: now that we expose a type from 3d party crate, it means any breaking change in many_cpus crate will be propagated as breaking change in thread_aware

Is there some other way to do it?

[sandersaares]

@Vaiz If you have specific proposals, please propose. Otherwise, this is not particularly new information and has already been considered. I was thinking it might be nice to split thread_aware into "the thread awareness part" and "the part that connects this with hardware" but it feels like a too big refactoring for now. Maybe something to file a future feature for? https://o365exchange.visualstudio.com/O365%20Core/_workitems/edit/7546921

[Vaiz]

@Vaiz If you have specific proposals, please propose. Otherwise, this is not particularly new information and has already been considered. I was thinking it might be nice to split thread_aware into "the thread awareness part" and "the part that connects this with hardware" but it feels like a too big refactoring for now. Maybe something to file a future feature for? https://o365exchange.visualstudio.com/O365%20Core/_workitems/edit/7546921

thread_aware should remove any dependency on many_cpus and have its own SystemHardware struct that can be constructed by consumer crates. So somewhere outside of thread_aware crate there will be a conversion of many_cpus::SystemHardware to thread_aware::SystemHardware

[martintmk]

yet another exposure to APIs that can change. thread_aware being such a foundational crate, I believe we should have a minimal "trait-only" crate that exposes bare minimum (ThreadAware trait, Affinity type) so libraries that expose these APIs can rely on stable crate.

[sandersaares]

thread_aware should remove any dependency on many_cpus and have its own SystemHardware struct that can be constructed by consumer crates. So somewhere outside of thread_aware crate there will be a conversion of many_cpus::SystemHardware to thread_aware::SystemHardware

Thanks for concrete suggestion! I am not going to go down this path because it would require reinventing the entire SystemHardware functionality - wrapping something behind another layer is not desirable cost/benefit. This exposure is not an accident or a byproduct - it is intentional. Just, ideally it would only be exposed to hosters of thread-aware types (runtime authors) and to advanced authors of thread-aware types (for testing) but not necessarily consumers of them. Today, we are not there yet but in the future we can be there (but not in scope of this PR).