Parallel execution uses deterministic reservation plus bounded native workers.
It does not share a mutable durable_context between threads.
Before workers start, the caller context reserves every branch or map-iteration operation in input order. Each worker receives a forked context positioned immediately before its reserved index. Scheduling order therefore cannot affect operation IDs, names, subtypes, or parent IDs.
max_concurrency sets the number of std::jthread workers. A value of zero
uses std::thread::hardware_concurrency() with a fallback of four workers.
A completed or failed branch releases its worker to process the next branch. A suspended branch retains its logical slot: that worker exits instead of starting another item. On the next durable invocation, replayed completed branches return quickly and suspended branches occupy the same bounded prefix of work.
Threshold and custom completion policies stop assigning new work. Items that never started, or remained suspended when the parent completed early, are recorded as cancelled in the aggregate result.
C++ cannot safely terminate arbitrary synchronous user code. A branch already executing runs to its next normal return, exception, or durable suspension, and the executor joins it before returning. Callables that need cooperative cancellation should implement it explicitly in application code.
execution_state::enable_checkpoint_batching() activates an RAII scope. Outside
that scope, checkpoints call the service directly.
Inside the scope:
- the first contending caller becomes the processor;
- other callers append immutable update copies and wait;
- the processor groups requests up to 250 operations and approximately 750 KiB by default;
- one service request consumes the current checkpoint token;
- immutable operation snapshots are published before waiting callers resume.
The default 100-microsecond coalescing window applies only inside an enabled
batching scope. It trades negligible local delay against fewer network calls.
Limits and the delay are configurable through checkpoint_batcher_config.
Any batch failure is propagated to every waiting request. The batching scope is normally owned by the parallel executor and ends only after all worker calls have returned.
The SDK guarantees concurrent safety for:
- operation history lookup and replacement;
- checkpoint token consumption;
- service calls issued through one
execution_state; - built-in parallel/map result aggregation.
Application callables and custom serializers invoked concurrently must either be immutable or provide their own synchronization.