Fix Linux batch-pool deadlock (force spawn start method)

.github/workflows/ci.yml

@@ -13,6 +13,7 @@ jobs:
   test:
     name: test (${{ matrix.os }}, py${{ matrix.python }})
     runs-on: ${{ matrix.os }}
+    timeout-minutes: 20  # the suite runs in ~2 min; fail fast instead of hanging 6 h
     strategy:
       fail-fast: false
       matrix:

CHANGELOG.md

@@ -45,6 +45,9 @@ First public release.
 - Batch sinks are correct across re-runs: a file sink is keyed by `(key, method)`, a
   directory sink refuses a mismatched `chunk_size` on resume, and a CSV sink asked to
   store raw spectra fails loudly rather than dropping the columns.
+- The batch process pool uses the `spawn` start method on every platform, so a CPU/GPU
+  pool no longer deadlocks on Linux (the default `fork` copies parent native thread pools
+  / CUDA contexts into the workers).
 
 ### Validated
 

src/cuperiod/batch/runner.py

@@ -16,6 +16,7 @@
 from __future__ import annotations
 
 import json
+import multiprocessing
 import warnings
 from collections.abc import Mapping, Sequence
 from concurrent.futures import ProcessPoolExecutor, as_completed
@@ -401,8 +402,14 @@ def _run_pool(
     initializer: Any = None,
     initargs: tuple[Any, ...] = (),
 ) -> None:
+    # Always use "spawn". Linux's default "fork" copies the parent's already-built
+    # native thread pools (numba / OpenBLAS / OpenMP, plus any CUDA context for the
+    # GPU pool) into the child and deadlocks the workers. Spawn starts fresh,
+    # thread-pinned workers (the Windows/macOS default) — see pin_worker_threads.
+    ctx = multiprocessing.get_context("spawn")
     with ProcessPoolExecutor(
-        max_workers=max_workers, initializer=initializer, initargs=initargs
+        max_workers=max_workers, mp_context=ctx,
+        initializer=initializer, initargs=initargs,
     ) as pool:
         futures = {
             pool.submit(_process_chunk, chunks[idx], cfg): idx for idx in pending