rjmholt
commented
4 years ago I've been thinking about this too, and wrote a simple consumer that allows asynchronous dispatch of PowerShell commands like this:
public class AsyncPowerShell
{
private readonly PowerShell _pwsh;
private readonly Runspace _runspace;
private readonly BlockingCollection<Tuple<PSCommand, TaskCompletionSource<IReadOnlyCollection<PSObject>>>> _commandQueue;
private readonly Thread _pwshThread;
private readonly CancellationTokenSource _cancellationSource;
public AsyncPowerShell()
{
_commandQueue = new BlockingCollection<Tuple<PSCommand, TaskCompletionSource<IReadOnlyCollection<PSObject>>>>();
_cancellationSource = new CancellationTokenSource();
_runspace = RunspaceFactory.CreateRunspace();
_runspace.Open();
_pwsh = PowerShell.Create();
_pwsh.Runspace = _runspace;
_runspace.Debugger.DebuggerStop += OnDebuggerStop;
_pwshThread = new Thread(RunPwshConsumer);
_pwshThread.Start();
}
public Task<IReadOnlyCollection<PSObject>> ExecutePowerShellAsync(string command)
{
var completionSource = new TaskCompletionSource<IReadOnlyCollection<PSObject>>();
_commandQueue.Add(new Tuple<PSCommand, TaskCompletionSource<IReadOnlyCollection<PSObject>>>(new PSCommand().AddCommand(command), completionSource));
return completionSource.Task;
}
public void Stop()
{
_commandQueue.CompleteAdding();
_cancellationSource.Cancel();
_pwshThread.Join();
}
private void RunPwshConsumer()
{
try
{
foreach (Tuple<PSCommand, TaskCompletionSource<IReadOnlyCollection<PSObject>>> executionRequest in _commandQueue.GetConsumingEnumerable(_cancellationSource.Token))
{
try
{
_pwsh.Commands = executionRequest.Item1;
executionRequest.Item2.SetResult(_pwsh.Invoke());
}
catch (OperationCanceledException)
{
executionRequest.Item2.SetCanceled();
}
catch (Exception e)
{
executionRequest.Item2.SetException(e);
}
finally
{
_pwsh.Commands.Clear();
}
}
}
catch (OperationCanceledException)
{
// End nicely
}
}
private void OnDebuggerStop(object sender, DebuggerStopEventArgs args)
{
Console.WriteLine("Debugger stopped");
}
}I think with some added sophistication, we could build off such a model to add:
- Nested prompt and debugging support
- Per-execution cancellations, allowing us to skip particular requests
- An implementation based on PowerShell's BeginInvoke and EndInvoke methods
- Cancellation that works into PowerShell's own pipeline cancellation mechanisms
The only part I don't quite understand in your description @SeeminglyScience is why we need another thread for message dispatch.
@daxian-dbw might also be interested in this discussion
SeeminglyScience
daxian-dbw
TylerLeonhardt
PaulHigin
A lot of the problems we face is based around handling of the pipeline thread. In order to invoke something on it, we need to interact with the
PowerShellclass, making us invoke at least a small bit of script in most cases. The reason for this is that the actual thread used by PowerShell is internal to the runspace by default. The only way to access it is to invoke a command of some sort.This is the default experience, but we can change it.
Runspacehas a property calledThreadOptions. One of the choices for that enum isUseCurrentThread. So what we can do is start our own thread, create the runspace there with that option, and never give up that thread.One of the biggest wins here would be that we could call
PSConsoleReadLine.ReadLinedirectly without having to invoke something. We could also ditch using the thread pool to wait forPowerShell.Invoketo finish (which probably causes some dead locks). We could get rid of a lot of the more complicated code inPowerShellContext.I'm pretty confident that if this doesn't outright solve a lot of the sluggishness and dead locks, it'll at the very least be significantly easier to debug.
The rest of this post is taken from #980 since the idea is the same:Nvm, just look at @rjmholt's code and the rest of conversation. The linked post is pretty outdated.