Start-Job vs. RunspacePool for High-Frequency Background Task Cancellation

Answer

For workloads that start and cancel many background tasks per second, RunspacePool is usually the better choice because its per‑task overhead is far lower than the process‑per‑job cost of Start‑Job. Reliable cancellation can be achieved cooperatively (via a cancellation token or PowerShell.Stop()); there is no documented hard‑kill method that works inside a runspace without risking the host process.

Confirmed facts

• Start‑Job launches a separate PowerShell process, giving strong isolation but incurring noticeable startup and memory overhead.
• RunspacePool reuses runspaces in the same process, providing low latency and lightweight execution suitable for high‑frequency scenarios.
• Cancelling a job is done with Stop‑Job (process termination). Cancelling a runspace relies on the script checking a cancellation token or responding to PowerShell.Stop(); if the script does not poll, cancellation may be delayed.

Likely explanation

The overhead of creating and tearing down a PowerShell process for each task dominates when tasks are short‑lived and numerous. Process isolation is only required when tasks need separate module versions, distinct security contexts, or must avoid any side‑effects on the host session. In the absence of such isolation needs, the safety benefit of Stop‑Job does not justify its cost.

Steps to implement cooperative cancellation with RunspacePool

1. Create a RunspacePool with appropriate minimum and maximum runspace counts (e.g., [RunspaceFactory]::CreateRunspacePool(1, [Environment]::ProcessorCount)).
2. Open the pool.
3. For each background task:
   • Create a PowerShell instance and set its RunspacePool to the pool.
   • Add the script block and any arguments.
   • Add a cancellation token (e.g., [System.Threading.CancellationTokenSource]::new().Token) as an argument or use AddArgument($token).
   • Call BeginInvoke() to start the task asynchronously and store the IAsyncResult.
4. To cancel a task:
   • Signal the cancellation token (tokenSource.Cancel()) or call PowerShell.Stop() on the instance.
   • Optionally call EndInvoke() to clean up.
5. When all work is done, dispose of the PowerShell instances and finally dispose of the RunspacePool.

Missing diagnostic detail

Do you require full environmental isolation (different module versions, separate security contexts, or guaranteed absence of side‑effects) for your background tasks? If the answer is yes, the process isolation of Start‑Job becomes necessary despite its higher overhead.