feat(stabilization)!: thread_aware 1.0 by martintmk · Pull Request #643 · microsoft/oxidizer

martintmk · 2026-08-06T13:37:46Z

Summary

Adds thread_aware_core 1.0.0 with the stable ThreadAware trait, Affinity type, and pinned_affinities topology helper.
Keeps the core crate dependency-free and always no_std; an opt-in std feature adds standard-library implementations for HashMap, Path, and PathBuf.
Re-exports the stable APIs directly from thread_aware, preserving thread_aware::ThreadAware and thread_aware::affinity::{Affinity, pinned_affinities} for downstream users.
Removes external-crate integration features and documents the stable boundary and affinity invariants.

Validation

thread_aware_core and thread_aware tests and doctests pass with all applicable features.
Both crates compile without default features.
thread_aware_core packages and verifies successfully with zero dependencies.
Formatting, generated README, spelling, Clippy, mutation, coverage, and external-type checks pass.
Independent Claude and Gemini reviews completed; their documentation findings were addressed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3a761577-6422-4fd1-a0f7-88807d7f6134

codecov · 2026-08-06T14:06:18Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (af4bdaa) to head (6244971).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##             main     #643     +/-   ##
=========================================
  Coverage   100.0%   100.0%             
=========================================
  Files         543      550      +7     
  Lines       60394    61487   +1093     
=========================================
+ Hits        60394    61487   +1093

Flag	Coverage Δ
linux	`94.1% <100.0%> (?)`
linux-arm	`94.2% <100.0%> (?)`
windows	`94.2% <100.0%> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

github-actions · 2026-08-12T11:52:29Z

✅ Version increments look sufficient

cargo semver-checks compared the 1 crate(s) this PR publishes against their previous version-bump commit in git history. Every version increment is sufficient for the detected API changes.

Crate	Baseline	Baseline commit	This PR	Minimum required	Status
`thread_aware_core`	new crate	—	1.0.0	1.0.0	✅ ok

This check is informational and does not block the merge.

View the check run

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

Make the stable core crate dependency- and feature-free, and remove external-type implementations and their benchmarks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

Keep the core crate dependency-free while providing Path, PathBuf, and HashMap implementations behind an opt-in std feature. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

martintmk · 2026-08-18T13:15:00Z


 #[doc(inline)]
-pub use crate::core::ThreadAware;
+pub use thread_aware_core::ThreadAware;


the _private module should not exist, thread_aware just re-exports the types from thread_aware_core directly

🤖 Agreed - I’ll remove the private wrapper and re-export the core types directly.

_{AI response generated by rocket}

🤖 Fixed: removed thread_aware::__private; the trait is now re-exported directly from thread_aware_core at the crate root.

_{AI response generated by rocket}

martintmk · 2026-08-18T13:16:02Z

imho, this could me moved to thread_aware_core, check if we can hide the constructor on Affinity again if this is moved

🤖 Agreed - I’ll move this into thread_aware_core and check whether Affinity can hide its constructor again.

_{AI response generated by rocket}

🤖 Fixed: moved pinned_affinities into thread_aware_core and made thread_aware::affinity a direct re-export. Affinity::new still needs public visibility because thread_aware::registry constructs arbitrary hardware mappings from a sibling crate; hiding it would require moving the registry or adding another public construction backdoor.

_{AI response generated by rocket}

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martintmk · 2026-08-19T08:03:22Z

 /// create per-core state: they ignore relocation and behave identically
 /// regardless of which core they run on.
-#[derive(Clone, ThreadAware)]
+#[derive(Clone, thread_aware::ThreadAware)]


Suggested change

#[derive(Clone, thread_aware::ThreadAware)]

#[derive(Clone, ThreadAware)]

(and rever similar changes)

🤖 Agreed - I’ll restore the derive here and revert the similar manual implementations introduced by this PR.

_{AI response generated by rocket}

🤖 Fixed: restored unqualified ThreadAware derives and the existing thread_aware re-export imports across downstream crates. The redundant direct thread_aware_core dependencies were removed as well.

_{AI response generated by rocket}

martintmk · 2026-08-19T08:05:32Z

-    "thread_aware::core::ThreadAware",
-    "thread_aware::affinity::MemoryAffinity",
-    "thread_aware::affinity::PinnedAffinity",
+    "thread_aware_core::ThreadAware",


how about thread_aware_core::Affinity

🤖 I don’t think thread_aware_core::Affinity should be added here. The external-type check reports only thread_aware_core::ThreadAware for tick’s public API; adding Affinity would create an unused approval rather than cover an exposed type.

_{AI response generated by rocket}

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martin-kolinek · 2026-08-19T08:26:15Z

+    /// Panics if either count is zero or an index is outside its corresponding
+    /// count.
+    #[must_use]
+    pub const fn new(processor_index: u16, memory_region_index: u16, processor_count: u16, memory_region_count: u16) -> Self {


Are we sure that these are the four properties we can stabilize? What if we need to further enrich Affinity in the future? Should we have a builder here perhaps?

🤖 The private fields let us add derived or optional state later without breaking struct construction, and we can add new constructors or a builder additively. The main commitment here is the four-argument Affinity::new contract plus its Copy/equality semantics. I’d keep the current constructor rather than stabilize a builder preemptively, but leave this thread open for the API-design decision.

_{AI response generated by rocket}

AI got little bit trigger happy, I have disabled automatic responses for humans. Let's discuss this (as humans :D)

There is also inconsistency in what types are accepted in the construct and how these are exposed through properties (u16 vs usize).

Also another alternative if we are not sure about the constructor:

Leverage _private module and expose a pub-internal new_affinity API that could be consumed in thread_aware.

Full sem-ver guarantees but it's not visible to users anymore.

Did we agree that _private modules are acceptable? I thought they would generally break with cargo doing updates.

I see two options:

Make affinities more opaque - don't expose the indices and counts at all, and just have the pinned_affinities function that produces a bunch of opaque affinities.

Agree that this list of affinity properties makes sense.

I'd lean towards the former in the first iteration, but we'll have to figure out the list of affinity properties at some point.

Did we agree that _private modules are acceptable? I thought they would generally break with cargo doing updates.

There is nothing special about _private module. Full SemVer guarantees need to be preserved between updates. It is just that we have lower API quality gate for items in _private module. Used as a last resort.

Make affinities more opaque

Making Affinity opaque makes sense to me. Let's see if this is feasible.

AI: Can you checked whether it is safe to make Affinity type opaque?

[AI Agent]

I checked all workspace consumers. Making construction opaque is safe and straightforward: Affinity::new is only needed by thread_aware_core::pinned_affinities, tests, and ThreadRegistry::affinities; the registry can instead derive per-region counts and consume pinned_affinities, so new can become private.

Making the properties fully opaque is feasible, but not a surgical visibility change. ThreadRegistry::pin_to, PerCore, PerNuma, Storage, and the anyspawn example currently consume the index/count accessors. Rust has no friend-crate visibility, so moving those accessors to a #[doc(hidden)]/_private public API would still leave a SemVer surface. A genuinely opaque design should remove the accessors and refactor consumers to operate on opaque identity/grouping instead—for example, registry-owned affinity-to-processor lookup plus storage keyed/grouped by affinity (potentially with an opaque memory-region identity). That also gives us a place to reject affinities not produced for the registry, rather than trusting a caller-provided processor index.

Recommendation: make Affinity::new private now and expose only pinned_affinities; treat removal of all four accessors as a small coordinated redesign rather than hiding them behind a private-looking public module. No code changes made pending agreement on the grouping API needed by PerNuma.

Recommendation: make Affinity::new private now and expose only pinned_affinities;

Proceed with this change

🤖 Fixed in d48b4e88: Affinity::new is now private, and ThreadRegistry constructs its values exclusively through pinned_affinities. Registry processor ordering is grouped by dense NUMA region so affinity indices continue to map correctly when pinning.

_{AI response generated by rocket}

Also hide the public accessors

martin-kolinek · 2026-08-19T08:27:27Z

+[package]
+name = "thread_aware_core"
+description = "Stable core traits and types for thread-aware state."
+version = "1.0.0"


Are we sure we can go straight to 1.0? Should we be a bit more conservative and give ourselves a week or two of 0.1?

🤖 A short 0.1 soak would reduce release risk, but it would also postpone the stable boundary this PR is explicitly creating. My recommendation is to keep 1.0 only if we consider the trait contract and Affinity semantics settled after this review; otherwise, publish 0.1 first and promote after the soak. I’m leaving this open for the release decision.

_{AI response generated by rocket}

I would say we can go with alpha, i.e. 1.0.0-alpha.1 (or something in that sense)

I remember pre-releases causing a bunch of challenges for interoptopus. I'd probably rather just go with 0.1 in the first few weeks.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martintmk · 2026-08-19T09:09:33Z

+/// runtime that created the value. An `Affinity` is a logical identifier; it does
+/// not pin the current thread or change operating-system scheduling.
+#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
+pub struct Affinity {


review this type and fields it uses and ensure this model aligns well with how NUMA nodes are used/modelled in real processors. Try to find any gaps or potential blockers/breaking changes we would have to make if we stick with this model.

use multi models to research this area thoroughly

🤖 Understood - I’m starting a multi-model review focused on whether the Affinity representation matches real NUMA and processor topologies, and on API choices that could force future breaking changes.

_{AI response generated by rocket}

🤖 Multi-model review complete (Opus, Sonnet, and GPT). The reviewers independently converged on these risks:

High-confidence correctness issue

thread_aware/src/registry.rs:98-140 uses numa_nodes.len() as memory_region_count, but that vector is indexed by the raw OS memory-region ID and may contain holes. For sparse IDs such as {2, 7}, affinities get dense region indices {0, 1} but report a count of 8. Track the distinct dense-region count separately, or use a raw-ID-to-dense-index map.

High API and correctness risks

Affinity::new permits callers to fabricate topology metadata, while ThreadRegistry::pin_to trusts only processor_index. An affinity from another registry can therefore pin the wrong physical processor or cause current_affinity() to report topology the registry never created. Construction should be opaque/fallible, or pin_to must validate registry/topology identity.

processor_index is a dense ordinal over the registry's selected logical processors, not a physical core index or OS processor ID. Two registries can produce equal affinities for different hardware, while the same hardware can compare unequal when topology counts differ. Equality/hash semantics need an explicit topology identity or a clearly enforced registry-local contract.

The public four-u16 constructor freezes argument order, widths, and count semantics. The u16 inputs versus usize accessors are also inconsistent. Hiding raw construction behind a documented factory/builder and accepting domain-appropriate typed values would preserve more room before stabilization.

Model scope to decide explicitly

Real systems also expose socket/package, logical processor versus physical core/SMT sibling, Windows processor group, sparse OS IDs, and heterogeneous-core efficiency class. Private fields and additive accessors can be added later without breaking callers, but changing constructor, equality/hash, or the meaning of processor_index cannot. The type should explicitly be either a registry-local locality coordinate or a fuller hardware-topology identity.

Lower-priority fixes

Use checked addition in pinned_affinities before narrowing the processor count.

The registry's < u16::MAX assertion rejects a count that u16 can represent; use <= if the narrow representation remains.

Recommendation before stabilizing: fix sparse NUMA counting, make construction opaque or topology-validated, define equality/identity semantics, rename/document the logical-processor ordinal precisely, and use the proposed alpha release to validate that contract.

No code changes were made from this review.

_{AI response generated by rocket}

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

github-actions · 2026-08-19T11:09:52Z

⚠️ Potential breaking changes detected

cargo semver-checks flagged the following on this PR. This is informational -- breaking changes between commits are expected; the major-version bump happens at release time, not on every PR.

`thread_aware`

     Cloning origin/main
    Building thread_aware v0.9.0 (current)
       Built [   5.205s] (current)
     Parsing thread_aware v0.9.0 (current)
      Parsed [   0.004s] (current)
    Building thread_aware v0.9.0 (baseline)
       Built [   5.974s] (baseline)
     Parsing thread_aware v0.9.0 (baseline)
      Parsed [   0.005s] (baseline)
    Checking thread_aware v0.9.0 -> v0.9.0 (no change; assume minor)
     Checked [   0.019s] 196 checks: 191 pass, 5 fail, 0 warn, 49 skip

--- failure feature_missing: package feature removed or renamed ---

Description:
A feature has been removed from this package's Cargo.toml. This will break downstream crates which enable that feature.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#cargo-feature-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/feature_missing.ron

Failed in:
  feature bytes in the package's Cargo.toml
  feature http in the package's Cargo.toml
  feature uuid in the package's Cargo.toml
  feature jiff02 in the package's Cargo.toml

--- failure function_missing: pub fn removed or renamed ---

Description:
A publicly-visible function cannot be imported by its prior path. A `pub use` may have been removed, or the function itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/function_missing.ron

Failed in:
  function thread_aware::affinity::pinned_affinities, previously in file /home/runner/work/oxidizer/oxidizer/target/semver-checks/git-origin_main/b88820a54d7bddbaad5a0ee32332b9a2f6e0d949/crates/thread_aware/src/affinity.rs:69

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/struct_missing.ron

Failed in:
  struct thread_aware::affinity::Affinity, previously in file /home/runner/work/oxidizer/oxidizer/target/semver-checks/git-origin_main/b88820a54d7bddbaad5a0ee32332b9a2f6e0d949/crates/thread_aware/src/affinity.rs:13

--- failure trait_missing: pub trait removed or renamed ---

Description:
A publicly-visible trait cannot be imported by its prior path. A `pub use` may have been removed, or the trait itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/trait_missing.ron

Failed in:
  trait thread_aware::ThreadAware, previously in file /home/runner/work/oxidizer/oxidizer/target/semver-checks/git-origin_main/b88820a54d7bddbaad5a0ee32332b9a2f6e0d949/crates/thread_aware/src/core.rs:73

--- failure trait_removed_supertrait: supertrait removed or renamed ---

Description:
A supertrait was removed from a trait. Users of the trait can no longer assume it can also be used like its supertrait.
        ref: https://doc.rust-lang.org/reference/items/traits.html#supertraits
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.46.0/src/lints/trait_removed_supertrait.ron

Failed in:

     Summary semver requires new major version: 5 major and 0 minor checks failed
  supertrait thread_aware::ThreadAware of trait ThreadAwareAsyncFnMut in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:66
  supertrait thread_aware::ThreadAware of trait ThreadAwareAsyncFn in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:58
  supertrait thread_aware::ThreadAware of trait ThreadAwareFnMut in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:42
  supertrait thread_aware::ThreadAware of trait ThreadAwareFn in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:34
  supertrait thread_aware::ThreadAware of trait ThreadAwareFnOnce in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:26
  supertrait thread_aware::ThreadAware of trait ThreadAwareAsyncFnOnce in file /home/runner/work/oxidizer/oxidizer/crates/thread_aware/src/closure/mod.rs:50
    Finished [  11.997s] thread_aware

Sander Saares (sandersaares) · 2026-08-19T10:42:38Z

+/// runtime that created the value. An `Affinity` is a logical identifier; it does
+/// not pin the current thread or change operating-system scheduling.
+#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
+pub struct Affinity {


Let's split the type definitions out into separate files, please - I went looking for affinity.rs and was confused about where the code was. lib.rs and mod.rs should be reserved for structural content to avoid surprises.

Sander Saares (sandersaares) · 2026-08-19T10:54:57Z

+    memory_region_count: u16,
+}
+
+impl Affinity {


We run into some API design issues here that are perhaps already embodied in ThreadAware and make it cumbersome to stabilize. Perhaps we need to actually do a proper API evolution and cleanup of ThreadAware APIs themselves before we stabilize anything?

I personally would like to see a design document that lays out the design tenets of ThreadAware and how it is meant to function - it has sort of accumulated stuff and transformed 4 different times over the years and I do not really have a feel for it, it has always been something I stumble through. Perhaps a design document + discussion would be fruitful on this topic.

Anyway, looking at some specifics here.

For one, calling this type Affinity is misleading - the name suggests it implies some data is actually affine to the Affinity but that's not really the case. If you have a thread_aware::Arc<T, PerProcess> then whatever value Affinity has is meaningless. And if you have a thread_aware::Arc<T, PerNuma> then half of it (the core number) is meaningless. The actual decision of "what am I affine to" is made by the thread-aware type itself. Affinity therefore does not signify affinity. This implies, at minimum, that the thing is misnamed. I suggest something like ThreadContext or just Context here - these are descriptors of a specific thread in context of which a relocation is happening.

For another, as a robot in a neighboring thread already noted, the coordinate space of these dimensions is unspecified. Processor index in what range of values? Memory region index in what range of values? Nothing defines that and there is no universal definition we can assume. Any index/count we provide must have a defined coordinate space - what are we counting/indexing exactly? How do we map to sparse "true" coordinate spaces (e.g. a machine processors 1 and 399 only)? pinned_affinities() de-facto partially defines the coordinate space as a dense one without ever actually saying it out loud, creating a lot of confusion here. Today, consumers of pinned_affinities() and Affinities just have to magically align with the undocumented assumptions in this function. Let's document this whole topic.

Sander Saares (sandersaares) · 2026-08-19T10:56:02Z

+/// not pin the current thread or change operating-system scheduling.
+#[derive(Copy, Clone, Debug, PartialEq, Eq, Hash)]
+pub struct Affinity {
+    processor_index: u16,


These fields all require values. How can we represent relocation to/from threads that are not pinned to a processor or memory region?

Sander Saares (sandersaares) · 2026-08-19T11:00:45Z

+    processor_index: u16,
+    memory_region_index: u16,
+    processor_count: u16,
+    memory_region_count: u16,


It is not obvious to me why these are u16 if they are only ever accessed as usize

Sander Saares (sandersaares) · 2026-08-19T11:07:28Z

+/// Panics if there are more than `u16::MAX` processors or memory regions.
+#[must_use]
+#[expect(clippy::needless_range_loop, reason = "clearer in this case")]
+pub fn pinned_affinities(counts: &[usize]) -> alloc::vec::Vec<Affinity> {


The probability of needing it is somewhat low but we should have a non-breaking migration path to a universe where we add additional coordinates to threads, such as "cache domains" (e.g. to subdivide a memory region into multiple sub-regions - these already exist today, physically, but we are somewhat behind the curve in modeling hardware realities so we have not used/needed such concepts today).

This assumes that callers who are creating Affinity objects without knowledge of these extended concepts should have a way to continue creating them. A single free function with a fixed behavior feels slightly strange, as we would have to add a second function alongside to provide support for such concepts. A builder seems more generalizable.

Sander Saares (sandersaares) · 2026-08-19T11:11:40Z

+/// remain correct when relocation is not reported, is reported more than once, or
+/// uses equal source and destination affinities.
+///
+/// # Example


This example does not really seem to show off a meaningful implementation - it is an API dummy with no useful behavior. A more useful example would showcase how the function is used to achieve some realistic goal (i..e. specializing behavior for some purpose). We just made some claims about performance and contention-avoidance mechanisms above but only showcase how to set the value of a field.

Sander Saares (sandersaares) · 2026-08-19T11:12:21Z

+
+/// Marks state that can adapt after being transferred between affinities.
+///
+/// Implementations commonly recreate affinity-local resources, select a


Not sure what this paragraph means.

Sander Saares (sandersaares) · 2026-08-19T11:18:44Z

+pub trait ThreadAware: Send {
+    /// Adapts this value in place for the destination affinity.
+    ///
+    /// `source` is `None` when the value's previous affinity is unknown. Callers


It also seems worth mentioning whether implementations are expected to tolerate relocations across unrelated affinities (e.g. relocation 1 to "processor 5 of 10" and relocation 2 to "processor 19 of 2000"). I make no comment on what the expectation should be, merely that it is a question that implementors will have, so we should answer here.

Sander Saares (sandersaares) · 2026-08-19T11:22:52Z

+pub struct Affinity {
+    processor_index: u16,
+    memory_region_index: u16,
+    processor_count: u16,


IMO counts should be NonZero<T> to avoid completely unnecessary zero-checking path.

Explore an opaque, extensible redesign of the affinity descriptor: a Dimension-keyed LocalityId identity built through Affinity::builder, replacing the frozen four-number processor/memory-region shape. Unset dimensions are absent, and LocalityId is an opaque Copy+Eq+Hash key created from a u16 index or a static name. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

…conflict) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

docs(thread_aware): add stabilization notes

f9b0170

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3a761577-6422-4fd1-a0f7-88807d7f6134

martintmk added the agency-rocket Touched by a rocket skill label Aug 6, 2026

docs(thread_aware): clarify pending stabilization choices

adb372b

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3a761577-6422-4fd1-a0f7-88807d7f6134

martintmk changed the title ~~docs(thread_aware): add stabilization notes~~ feat(stabilization)!: stabilize thread_aware 1.0 Aug 6, 2026

docs(thread_aware): generalize downstream stabilization note

c6f18f2

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3a761577-6422-4fd1-a0f7-88807d7f6134

martintmk changed the title ~~feat(stabilization)!: stabilize thread_aware 1.0~~ feat(stabilization)!: thread_aware 1.0 Aug 6, 2026

martintmk added 2 commits August 12, 2026 13:47

feat(thread_aware_core): stabilize core thread-aware API

1160b75

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

merge: integrate origin/main into PR branch (auto-resolved conflicts)

2b0ddaa

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

martintmk commented Aug 12, 2026

View reviewed changes

Comment thread crates/thread_aware_core/Cargo.toml

martintmk added 5 commits August 12, 2026 14:13

test(thread_aware_core): cover memory affinity indices

3042ac3

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix(thread_aware): satisfy nightly formatting

c16acb0

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix(thread_aware): sort manifest dependencies

503f84c

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix(thread_aware): remove unused dev dependency

a92c001

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

martintmk commented Aug 12, 2026

View reviewed changes

Comment thread crates/thread_aware_core/src/impls.rs

martintmk commented Aug 13, 2026

View reviewed changes

Comment thread crates/seatbelt/Cargo.toml

martintmk added 4 commits August 13, 2026 12:55

review: expose stable thread-aware core types directly

2d8c5e8

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix: avoid unused core trait imports

3b862bf

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix: match nightly import grouping

75b3d23

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

fix: qualify stable trait rustdoc link

4e75479

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 392f99fd-c9b0-40c7-aad7-3e87a132b16e

martintmk commented Aug 18, 2026

View reviewed changes

martintmk added 3 commits August 18, 2026 15:31

review(thread_aware): simplify core reexports

5446dd0

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

merge: integrate origin/main and update external type allowlists

8822c86

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

fix(deps): upgrade h2 to 0.4.16

28afb11

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martintmk commented Aug 19, 2026

View reviewed changes

review(thread_aware): keep downstream imports on reexports

9339537

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martin-kolinek reviewed Aug 19, 2026

View reviewed changes

docs(thread_aware_core): clarify affinity topology helper

f875c84

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

martintmk commented Aug 19, 2026

View reviewed changes

review(thread_aware): hide affinity construction

d48b4e8

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

Sander Saares (sandersaares) reviewed Aug 19, 2026

View reviewed changes

martintmk added 2 commits August 19, 2026 16:50

merge: integrate origin/main into PR branch (auto-resolved .spelling …

6244971

…conflict) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8f9c8e6e-73c6-47c0-830e-2f674656eceb

	#[derive(Clone, thread_aware::ThreadAware)]
	#[derive(Clone, ThreadAware)]

Uh oh!

Conversation

martintmk commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Uh oh!

codecov Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

github-actions Bot commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Version increments look sufficient

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Potential breaking changes detected

thread_aware

Uh oh!

martintmk commented Aug 6, 2026 •

edited

Loading

codecov Bot commented Aug 6, 2026 •

edited

Loading

github-actions Bot commented Aug 12, 2026 •

edited

Loading

github-actions Bot commented Aug 19, 2026 •

edited

Loading

`thread_aware`