Repository navigation
Common Parameters should include a CancellationToken #19685
Description
Summary of the new feature / enhancement
There have been a number of requests to add timeouts to various commands ( why always in seconds ? ) it would be simpler to add CancellationToken support to Common Parameters so that all commands automatically have the capability in a consistent manner.
While superficially a timeout might seem obvious and simple, a CancellationToken is far more useful and allows the client control over when the cancellation is requested, eg not just because of a timeout but because some other condition occurred after the command has been started.
Proposed technical implementation details (optional)
Proof of concept
This demonstrates a cancellation token working with Invoke-Command
Implementation - CommandWithCancellationToken.cs
Unit tests - CommandWithCancellationTokenTests.cs
Reacted by Manuel Berfelde and kasini3000
Activity
rhubarb-geek-nz commentedon May 20, 2023
The effect of the cancellation token should be inherited;
Perhaps the CancellationToken should be in a well-known variable like $ErrorActionPreference, eg as $CancellationToken.
There could be a $CancellationActionPreference to indicate how cmdlets should react when cancelled, eg if you want to opt out of the cancellation mechanism it could be set to Continue or Ignore, else it could be set to Stop. This would allow you to control how background processes are managed and whether they are automatically cancelled or not by the setting of this value when they are started.
rhubarb-geek-nz commentedon May 20, 2023
The cancellation mechanism is not intended to give any hint regarding how long to go before the cancellation occurs. A cancellation due to timeout is only one method, other cancellations may be caused by the user pressing control-C, or parallel search requests invoked and the first successful response cancels the uncompleted redundant requests.
rhubarb-geek-nz commentedon May 21, 2023
Existing Cmdlets should not need to change as the existing Cmdlet.StopProcessing mechanism should be used to cancel running cmdlets.
kasini3000 commentedon May 21, 2023
Both of these are required.
I reiterate that it is important for multithreading. Powershell is different from shell, as it works at the multi-threaded level.
PowerShell/ThreadJob#26
rhubarb-geek-nz commentedon May 21, 2023
This request is not about adding timeouts because a timeout can be implemented using a CancellationToken with CancelAfter , the reverse is not true. Once cancellation tokens are implemented then you have the ability to do timeouts.
rhubarb-geek-nz commentedon Nov 18, 2023
It would be nice to be triaged.
rhubarb-geek-nz commentedon Jan 18, 2024
GitHub Proof of concept
PowerShell gallery demonstration
Zetanova commentedon Apr 4, 2024
I found a method to get the SIGINT signal (windows and linux) from the pwsh.exe to be useable for sync-over-async calls on
gist signal-cancellation
rhubarb-geek-nz commentedon Apr 5, 2024
I don't think that signals should be used in PowerShell programming. A script or cmdlet should stop according to either PowerShell.Stop, exceptions, error handling or because a cancellation token has been signalled.
Signals should be managed by the top level process on the main thread and their scope is the entire process. A script or cmdlet should not care if it is the upper most script or a deeply nested script, run remotely, in a job or thread. It should have simple access to a cancellation token that tells it when it abort.
Zetanova commentedon Apr 5, 2024
Yes, until the powershell team implements something they dont want to implement for years.
This SignalToken can be used to abort scripts in the pwsh.exe on script creation time.
The other option is off to kill pwsh.exe and open it again.