From 057b21ba69af75db4c06fbeb0220812aa0e69cd2 Mon Sep 17 00:00:00 2001 From: davidamacey Date: Mon, 24 Aug 2026 22:57:42 -0400 Subject: [PATCH 1/2] docs: mark chunk_emb_workers as currently unused Confirmed by grep across the whole crate: no code path reads RuntimeConfig::chunk_emb_workers on either the CUDA or CoreML execution mode. Only the sibling chunk_emb_compute_units field is consumed, and only under the coreml feature. Document the gap rather than leave the field's purpose implied by its name (closes #13's underlying confusion until it's actually wired up). --- src/pipeline/config.rs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/pipeline/config.rs b/src/pipeline/config.rs index b457960..e61e018 100644 --- a/src/pipeline/config.rs +++ b/src/pipeline/config.rs @@ -75,7 +75,11 @@ impl PipelineConfig { /// Controls execution parameters that do not affect correctness but do affect performance. #[derive(Debug, Clone)] pub struct RuntimeConfig { - /// Number of chunk embedding workers + /// Number of chunk embedding workers. + /// + /// Currently unused: no code path reads this field on either the CUDA or CoreML + /// execution mode (verified against the whole crate — see #13). It's reserved + /// for a future worker-pool implementation; setting it has no effect today. pub chunk_emb_workers: usize, /// CoreML compute units for chunk embedding (CoreML modes only) #[cfg(feature = "coreml")] From afae2223dd1f5666ec71158f33c9d5ffc41b782b Mon Sep 17 00:00:00 2001 From: davidamacey Date: Mon, 24 Aug 2026 23:10:32 -0400 Subject: [PATCH 2/2] docs: clarify chunk_emb_workers is a CoreML-only concept, not CUDA chunk_emb_compute_units (the sibling field) is already gated to the coreml feature, and CoreML sessions can only run one at a time - so this field almost certainly exists to parallelize chunk embedding across several single-threaded CoreML workers, not to control CUDA concurrency. CUDA already gets concurrency a different way, from shared mutex-protected ORT sessions (see the shared-sessions PR). Nothing to wire up on the CUDA path. --- src/pipeline/config.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/pipeline/config.rs b/src/pipeline/config.rs index e61e018..448e5e2 100644 --- a/src/pipeline/config.rs +++ b/src/pipeline/config.rs @@ -78,8 +78,13 @@ pub struct RuntimeConfig { /// Number of chunk embedding workers. /// /// Currently unused: no code path reads this field on either the CUDA or CoreML - /// execution mode (verified against the whole crate — see #13). It's reserved - /// for a future worker-pool implementation; setting it has no effect today. + /// execution mode (verified against the whole crate — see #13). Its sibling field + /// below, `chunk_emb_compute_units`, is CoreML-only, and CoreML sessions can only + /// run one at a time — so this almost certainly exists to parallelize chunk + /// embedding across several single-threaded CoreML workers rather than to control + /// CUDA concurrency (CUDA already gets concurrency from shared, mutex-protected + /// ORT sessions). It's reserved for that future CoreML worker-pool implementation; + /// setting it has no effect today on any mode. pub chunk_emb_workers: usize, /// CoreML compute units for chunk embedding (CoreML modes only) #[cfg(feature = "coreml")]