feat(Task, Async): parallelLimit, sequential, startAsyncImmediate

[bartelink]

Part of the helpers/signatures proposed in fsharp/fslang-suggestions#1467

Resolves fsprojects/FSharp.Control.TaskSeq#143
Resolves fsharp/fslang-suggestions#1467

Adds parallelLimit, parallelDoLimit, sequential and sequentialDo functions for module Async and module Task (excluding Async.sequential as Async.Sequential already has same signature on type Async).

Adds Task.startAsyncImmediate (pipeline-friendly/pit-of-success alias for Async.StartImmediateAsTask that forces passing of a CancellationToken)

---

Limit vs Throttled naming is/was discussed in the linked issues; any discussion on naming should happen there

cc @TheAngryByrd This replicates functionality in FsToolkit.ErrorHandling so reviews would be much appreciated (and/or feel free to @ in anyone relevant)

cc @xperiandri Task.parallelLimit has same sig as CancelableTask.whenAllThrottled in #20128 (I intend to take the enhancement and review comments from there into account too)

Checklist:

• Address copilot review comments
• Add Task.sequential https://github.com/TheAngryByrd/IcedTasks/blob/ba4e932b71bfde354f0e2561c2519b282fe56ff9/src/IcedTasks/CancellableTask.fs#L554-L566
  • probably also Add Task.sequentialDo: CT -> seq<CT->Task<unit>> (same logic without result collector in mix)
• Add Task.startAsyncImmediate: CT -> Async'T> ->Task<'T> feat(Task, Async): parallelLimit, parallelDoLimit bartelink/fsharp#2 (comment) TaskEx: Async.startImmediateAsTask fsprojects/FSharp.Control.TaskSeq#142 Async/Task interop/cancellation/limits fsharp/fslang-suggestions#1467
  • in a separate PR if anyone insists

[github-actions]

✅ No release notes required

[Copilot]

Pull request overview

Adds bounded-parallelism helpers to FSharp.Core’s Async and Task modules (parallelLimit / parallelDoLimit), along with unit tests, surface-area baselines, and release notes, to support controlled concurrency for async/task workflows.

Changes:

• Add Async.parallelLimit / Async.parallelDoLimit wrappers over Async.Parallel with maxDegreeOfParallelism.
• Add Task.parallelLimit / Task.parallelDoLimit implemented via SemaphoreSlim + Task.WhenAll, flowing a provided CancellationToken to task factories.
• Add unit tests + surface area baseline updates + release note entry for the new APIs.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/TaskModuleFunctions.fs	Adds unit tests for Task.parallelLimit / Task.parallelDoLimit (results + concurrency cap).
tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/AsyncModuleFunctions.fs	Adds unit tests for Async.parallelLimit / Async.parallelDoLimit.
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard21.release.bsl	Surface-area baseline update for new AsyncModule/TaskModule members (netstandard2.1, release).
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard21.debug.bsl	Surface-area baseline update (netstandard2.1, debug).
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard20.release.bsl	Surface-area baseline update (netstandard2.0, release).
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard20.debug.bsl	Surface-area baseline update (netstandard2.0, debug).
src/FSharp.Core/tasks.fsi	Public API + docs for Task.parallelLimit / Task.parallelDoLimit.
src/FSharp.Core/tasks.fs	Implementation of Task.parallelLimit / Task.parallelDoLimit.
src/FSharp.Core/async.fsi	Public API + docs for Async.parallelLimit / Async.parallelDoLimit.
src/FSharp.Core/async.fs	Implementation of Async.parallelLimit / Async.parallelDoLimit.
docs/release-notes/.FSharp.Core/11.0.100.md	Release note entry for the new bounded-parallelism helpers.

Suppressed comments (1)

src/FSharp.Core/tasks.fs:820

• SemaphoreSlim disposal is wired up via a ContinueWith, but if enumerating computations throws while building the Task.WhenAll input array, the semaphore is leaked (the continuation is never attached). Using use sem = ... and dropping the continuation avoids the leak and simplifies the implementation.

            allTask.ContinueWith(
                (fun (_: Task<'T[]>) -> sem.Dispose()),
                CancellationToken.None,
                TaskContinuationOptions.ExecuteSynchronously,
                TaskScheduler.Default

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

🔍 Tooling Safety Check — Affects-Test-Tooling
Affects-Test-Tooling: XunitSetup.fs adds TestClassAttribute/Fact4Attribute shims controlling test parallelization

Generated by PR Tooling Safety Check · opus46 2.9M · ◷

[bartelink]

@T-Gro if you can chuck an AI or human review on this I'll attend to it
There are no ValueTask variants of any of the above even though I put one in fsharp/fslang-suggestions#1467; I've never personally needed them; should one be added for e.g. startAsyncImmediate ?

@T-Gro @TheAngryByrd In my musings in fsharp/fslang-suggestions#685 (comment) I noted that parallelLimit and friends should probably make an internal linked CT and cancel siblings where one of the computations faults in order to match the Async.Parallel semantics, thoughts? Assumed yes, applied the relevant cancellation semantics to the PR

@TheAngryByrd @T-Gro Any thoughts on whether we should add Async.StartChild(computation, externalCt) per fsharp/fslang-suggestions#685 into the mix?

@TheAngryByrd Are there any other common things that might belong in the modules that get heavy usage, e.g. ofUnitTask helpers or suchlike?

(Note I've merged in the RunSynchronously triage PR in on top so should not be merged first) trimmed that back out; hopefully this will build cleanly without it...

[bartelink]

@T-Gro bumping #20294 (comment)

The devil makes work for idle hands, so I added Async.sequentialDo to match the one in Task
This avoids having to do an Async.ignore<unit[]> in the common case of doing Async.Sequential with unit computations

Let me know if either is a step too far - IME this is common, and the Async.Ignore that people/autocomplete typically doesn't orce a type to be specified.