1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
/*
* SPDX-License-Identifier: MIT
* Copyright (c) 2023 - 2026. The DeepCausality Authors and Contributors. All Rights Reserved.
*/
//! Scoped fork-join over slices: the minimal in-house parallel-map surface
//! the workspace uses for **few, long-running, data-independent tasks**
//! such as counterfactual branch fan-outs and per-candidate evaluation
//! loops.
//!
//! [`scoped_map`] maps a function over a slice and returns the results in
//! input order. With the `parallel` feature the slice is split into
//! contiguous chunks, one per available core, and each chunk runs on a
//! [`std::thread::scope`] thread. The closure may therefore borrow from
//! the caller's stack; no thread pool is spun up, and a panic in any task
//! propagates on join. Without the feature it is exactly
//! `items.iter().map(f).collect()`; the [`MaybeParallel`] bounds are then
//! vacuous, so serial consumers see no `Send + Sync` requirements.
//!
//! This is deliberately not a work-stealing scheduler. Tasks are assumed
//! to be coarse and similar in cost, which is where a plain fork-join
//! matches Rayon without the dependency. For many small, irregular tasks a
//! real scheduler would win; nothing in the workspace needs one.
use Vec;
use crateMaybeParallel;
/// Map `f` over `items`, preserving input order in the returned `Vec`.
///
/// With the `parallel` feature the work fans out over scoped threads, one
/// contiguous chunk per available core; without it the map runs inline.
/// For a deterministic `f` the results are identical in both modes. The
/// split only changes where each element is computed, never the order of
/// the output.
///
/// # Panics
/// If `f` panics on any element, the panic propagates to the caller when
/// the scope joins (parallel) or immediately (serial).