Since this performs the same function as Ctrl+C signal, why not just use that? I thought we were going to implement Ctrl+Break as it was implemented before (stops running pipeline and exits process).

If so then it seems we should call the break handler like this:

SpinUpBreakHandlerThread(true);

BTW the previous implementation (before changing it to break into debugger) was to make absolutely sure that the process ends. I don't think we need to be this draconian but this was how it was implemented before:

                    // The Big Red Button!

                    // check if we are in a pushed session
                    // if so exit out of it
                    if (ConsoleHost.SingletonInstance.IsRunspacePushed)
                    {
                        ConsoleHost.SingletonInstance.PopRunspace();
                        HandleBreak();
                        return true;
                    }

                    // Log all sqm data before we exit.
                    System.Management.Automation.Sqm.PSSQMAPI.LogAllDataSuppressExceptions();
                    ConsoleHost.SingletonInstance.shouldEndSession = true;

                    ConsoleHandle handle = ConsoleControl.GetActiveScreenBufferHandle();
                    ConsoleControl.WriteConsole(handle, "\n" + ConsoleHost.exitOnCtrlBreakMessage);

                    unchecked
                    {
                        Environment.Exit((int)ExitCodeCtrlBreak);
                    }

@PaulHigin because I launch powershell in its own process group, ctrl+C is implicitly disabled for the lauched process and its children (see Remarks section of CreateProcess). This allows parent applications like my own to better control the propogation of SIGINT signals and prevent ctrl+c from broadcasting to all processes in the console.

I'll change shouldEndSession to true. I was blindly looking to imitate ctrl+c but true does make more sense. Thanks for the above snippet of the former behavior. I was looking for the state before entering the debugger yesterday and couldn't find it in the history.

I think sticking with SpinUpBreakHandlerThread is likely the best pattern to follow now.

Please use named parameters.

Please use named parameters.