14 Multitasking with background jobs

This chapter explains how PowerShell, though fundamentally single‑threaded, can multitask by running commands as background jobs. It contrasts synchronous execution—where you wait for a command to finish—with asynchronous jobs that free the console while work continues in the background. Key implications include no interactive prompting in jobs, deferred error visibility, and results that are retrieved after completion. The authors recommend perfecting commands synchronously first, then running them as jobs, and note that “jobs” are an extensibility point—this chapter focuses on the native, built‑in varieties.

PowerShell offers several ways to create jobs. Process jobs (Start-Job) run in a separate PowerShell process and can take a script block or a script file; use absolute paths or -WorkingDirectory, and expect a parent job with at least one child job. Thread jobs (Start-ThreadJob) run on another thread within the same process, start much faster, and are ideal for short tasks; they observe a throttle limit (10 by default) that you can raise, though returns diminish at high counts. Remoting can also run as a job (Invoke-Command -AsJob), fanning out a script block in parallel across many machines subject to a throttle (32 by default). Because commands execute on the targets, this distributes workload; it requires PowerShell 6+ and SSH-based remoting. Many modules (for example, Az) expose -AsJob to return manageable jobs from their cmdlets.

Managing jobs centers on Get-Job for status and Receive-Job for output. You can target parent or child jobs, note that results are cleared unless you use -Keep, and expect deserialized objects suitable for piping to other cmdlets. Child jobs are first-class and can be listed or received individually; they often explain partial failures in multi-target runs. Control commands include Wait-Job to block until completion, Stop-Job to terminate stuck work, and Remove-Job to free memory once output is collected (HasMoreData helps you decide). The chapter warns against nesting job mechanisms (for example, starting a local job inside a remoting session or wrapping Invoke-Command inside Start-Job) and reminds that jobs are per-session, user-isolated, and vanish when the PowerShell process ends. Exercises reinforce creating thread jobs for long searches, fanning them out to remotes, and preserving results in the job queue.

1. Start-ThreadJob {gci / -recurse –filter '*.txt'}
2. Invoke-Command –scriptblock {gci / -recurse –filter *.txt}

3. Receive-Job –id 1 –keep
   Of course, you would use whatever job ID was applicable or the job name.

FAQ