This will give back an async object, which can be used to monitor the state of our currently running background command.Īssuming that everything works out, we will eventually see that the background command has ended and I am free to retrieve the output and dispose of the PowerShell instance (so I do not have the possibility of memory leaks or something else).įirst things first. Instead of using Invoke() to kick off our commands, I will instead use BeginInvoke(). I need a better way to run a command in the background so the console can be open to do other things. Add a Start-Sleep –Seconds 10 in my example script block, and you will see what I mean.īefore I jump into some better multithreading examples, I am going to show the same example, but this time I am creating a runspace to work with and adding it to the PowerShell instance. What you may not know is that this is no different than what would run if I typed Get-Date in my console-which is not really useful if we want a way to run things in the background. Also look at where I used so that it doesn’t pollute my pipeline or anywhere in the output. The result of running this is simply the return of the current date and time. Note that this already has a runspace built-in, so I do not have to worry about creating a new runspace at this point. From there, I’ll add a script block and kick off the instance. To start off, I will make use of the type accelerator and use the Create() method to quickly create the instance.
My plan is to take difficulty that may appear with using runspaces and show you how quickly and simply you can kick off a command in a runspace and pull it back without breaking a sweat. Everything else happens behind the scenes. Using the built-in jobs framework makes this easy because you simply run something like Start-Job and then Receive-Job to get the data. Then you need to retrieve the information (if applicable) and tear down the runspace and PowerShell instance for disposal. Additionally, you have to manage the whole process by kicking off the instance and monitoring it for completion. The downside is the level of effort that is required to create the runspace and the PowerShell instance to run it. Runspaces create a new thread on the existing process, and you can simply add what you need to it and send it off running. Using runspaces is a great alternative to get around this issue. This can take up a lot of resources depending on how many jobs you plan to run. The main complaint in some of these efforts is that this causes another PowerShell process to be created and loaded with all of the format and type files, creating the PSDrives and such. Or you might use the –Asjob parameter that you see in some cmdlets, such as Get-WMIObject. You would usually use something related to PSJobs, such as the *-Job cmdlets. Let’s say you are working in PowerShell and you want to kick off something to run in the background while you are working on some other things in the console. A Look at the PoshRSJob Module Learn about a module for working with runspaces.Beginning Use of PowerShell Runspaces: Part 3 Use runspace pools for multithreading.Beginning Use of PowerShell Runspaces: Part 2 Begin use with runspaces.Beginning Use of PowerShell Runspaces: Part 1 Begin use with runspaces.
Note This is a four-part series that includes the following posts:
Honorary Scripting Guy and Cloud and Datacenter Management MVP, Boe Prox, here today filling in for my good friend, The Scripting Guy. Summary : Boe Prox presents some tips about beginning use with runspaces.