Control-C handler uses obsolete Thread.Abort

[orent]

Unhandled exception. System.PlatformNotSupportedException: Thread abort is not supported on this platform. at System.Threading.Thread.Abort(Object stateInfo) at Microsoft.Scripting.Hosting.Shell.BasicConsole.<.ctor>b__24_0(Object sender, ConsoleCancelEventArgs e) at Microsoft.Scripting.Hosting.Shell.BasicConsole.<.ctor>b__24_1(Object sender, ConsoleCancelEventArgs e) at System.Console.HandlePosixSignal(PosixSignalContext ctx) at System.Runtime.InteropServices.PosixSignalRegistration.<OnPosixSignal>g__HandleSignal|10_0(Object state) at System.Threading.Thread.StartCallback() Aborted (core dumped)

At first I assumed Thread.Abort is unsupported on Linux, but then I realized the API is now obsolete on all platforms. How hard would it be to add cancellation tokens and what would be the performance impact?

[slozier]

Thanks for the report. I'm not even sure how cancellation tokens would work since the threads can be running arbitrary code. There is the following issue which may be of interest: dotnet/runtime#41291

[BCSharp]

Related issues: IronLanguages/ironpython3#64, IronLanguages/ironpython3#1024, IronLanguages/ironpython3#1312.

One possibility would be to check for a cancellation toke state at the beginning of each interpreted frame run. Ctrl-C would cancel the token and issue Thread.Interrupt. This does not guarantee that the interrupt will be always effective, like if the thread is off in the bushes inside a third-party code, but on platforms that do not support Thread.Abort the only other thing that can be then done to stop it is to bring down the whole process. This was also my experience with some interactive Unix tools: if they are really stuck in an infinite loop, Ctrl-C wouldn't help, one needed to sent a stronger signal, like SIGTERM, SIGQUIT, or even SIGKILL.

There would be some performance impact, but I don't think it will be that big, it would need to be measured. Relatively speaking, executing an interpreted frame takes orders of magnitude longer than a simple token state check.

[orent]

Checking just once per frame will often result in Ctrl-C not working because many loops are contained entirely in a single frame. Performing the check somewhere that gets executed frequently like getting a CodeContext would be more reliable and hard or even impossible to get stuck using python code only. The question is whether the performance impact is going to be reasonable.

[slozier]

dotnet/runtime#71661