打破砂鍋：Ctrl-C 擋不住 Console.ReadLine() 繼續執行？

前幾天被一個詭異的 .NET 程式茶包卡住，還在 FB 貼文請大家幫忙測試。

我們都知道 .NET Console 程式執行過程，按下 Ctrl-C 可終止程式執行。若是在 Console.ReadLine() 等待輸入過程按下 Ctrl-C，直覺想法是既然 ReadLine() 會等待 Enter 鍵再繼續，Ctrl-C 非 Enter 鍵，又有終止程式的意義，程式應該會立即停止。

但以下的測試結果就讓人有點匪夷所思了：

Console.WriteLine("Before ReadLine()");
Console.Write("Enter something: ");
var line = Console.ReadLine();
Console.Write("Enter more: ");
var line2 = Console.ReadLine();
Console.WriteLine("After ReadLine()");

前後兩次 ReadLine()，第一次 ReadLine() 時按 Ctrl-C，程式會立刻結束；若第一次 ReadLine() 隨便給值按 Enter，第二次 ReadLine() 才按 Ctrl-C，則會印完 AfterReadLine() 程式才終止。

蒐集我自己及網友的測試結果，發現同樣的程式碼，相同 .NET 版本，有的人可以重現，有的人不行 (Linux/macOS 則沒有重現案例)，而 Bill 叔更分享了「問題重現與否跟手速有關」的發現，意思是此現象在第一次 ReadLine() 也會發生。如下圖，我們一律在第一次 ReadLine() 按 Ctrl-C，若時機夠早，程式有可能顯示完 "Enter more:" 才結束(下圖 [1], [3])；若慢一點，程式比較大機率直接結束。(帶有機率性，符合 Race Condition 的特性)

經過一番推敲，我釐清一件事實：判斷按下 Ctrl-C 的邏輯並不是由 ReadLine() 處理的，Ctrl-C 與 Ctrl-Break 對 Console 程式來說是種特殊訊號(SIGINT、SIGBREAK)，設有專屬的機制處理，依據官方文件：這些訊號會傳遞到已連結至主控台的所有主控台程序，系統會在每個客戶端進程中建立新的線程來處理事件。
(註：感謝讀者吳承信分享：Linux/macOS 處理 SIGINT 方式不同，會採用中斷 Main Thread 將執行權交給 Signal Handler 的做法，而非另開 Thread 處理，可解釋為何此一現象在 Linux/macOS 不會發生，故以下的討論僅適用 Windows。)

故按下 Ctrl-C 時，Console 程式會啟動一條 Thread 負責結束程式(姑且稱之為自我了結 Thread)，而此時 Main Thread 的 ReadLine() 也會因為按了 Ctrl-C 而結束等待，繼續往下執行。若自我了結 Thread 的速度不夠快，在 Main Thread 跑完 Console.Write() 後才把程式停掉，便會出現按了 Ctrl-C 但 ReadLine() 的下一行還是繼續執行的現象。由於自我了結 Thread 與 Main Thread 二者會平行處理，誰快誰慢具有隨機性。想通「結束程式與 ReadLine() 後方邏輯會平行執行」這點，上面遇到的各式不同結果便都有了合理解釋，一切也可歸納為 It's by design, not a bug。

至此本案的最大謎團算是解開了，但我還有個疑問：為什麼 Console.ReadLine() 遇到 Ctrl-C 會等同按了 Enter 繼續往下走？

我決定追進 .NET 原始碼一探究竟。

Console.ReadLine() 背後是呼叫 In.ReadLine()，而 In 是個 TextReader 型別，透過 ConsolePal.GetOrCreateReader() 建立。

public static TextReader In
{
    get
    {
        return Volatile.Read(ref s_in) ?? EnsureInitialized();

        static TextReader EnsureInitialized()
        {
            // Must be placed outside s_syncObject lock. See Out getter.
            ConsolePal.EnsureConsoleInitialized();

            lock (s_syncObject) // Ensures In and InputEncoding are synchronized.
            {
                if (s_in == null)
                {
                    Volatile.Write(ref s_in, ConsolePal.GetOrCreateReader());
                }
                return s_in;
            }
        }
    }
}

追到 ConsolePal.GetOrCreateReader()，得知 TextReader 其實是個 StreamReader。

internal static TextReader GetOrCreateReader()
{
    Stream inputStream = OpenStandardInput();
    return SyncTextReader.GetSynchronizedTextReader(inputStream == Stream.Null ?
        StreamReader.Null :
        new StreamReader(
            stream: inputStream,
            encoding: new ConsoleEncoding(Console.InputEncoding),
            detectEncodingFromByteOrderMarks: false,
            bufferSize: Console.ReadBufferSize,
            leaveOpen: true));
}

而 StreamReader ReadLine() 邏輯如下，等待使用者輸入再繼續的關鍵在 ReadBuffer()：(註：可留意有 **** 標示的中文註解處)

// Reads a line. A line is defined as a sequence of characters followed by
// a carriage return ('\r'), a line feed ('\n'), or a carriage return
// immediately followed by a line feed. The resulting string does not
// contain the terminating carriage return and/or line feed. The returned
// value is null if the end of the input stream has been reached.
//
public override string? ReadLine()
{
    ThrowIfDisposed();
    CheckAsyncTaskInProgress();

    if (_charPos == _charLen)
    {
        // **** 這裡會等待使用者輸入後再繼續
        if (ReadBuffer() == 0)
        {
            return null;
        }
    }

    var vsb = new ValueStringBuilder(stackalloc char[256]);
    do
    {
        // Look for '\r' or \'n'.
        ReadOnlySpan<char> charBufferSpan = _charBuffer.AsSpan(_charPos, _charLen - _charPos);
        Debug.Assert(!charBufferSpan.IsEmpty, "ReadBuffer returned > 0 but didn't bump _charLen?");

        int idxOfNewline = charBufferSpan.IndexOfAny('\r', '\n');
        if (idxOfNewline >= 0)
        {
            string retVal;
            if (vsb.Length == 0)
            {
                retVal = new string(charBufferSpan.Slice(0, idxOfNewline));
            }
            else
            {
                retVal = string.Concat(vsb.AsSpan(), charBufferSpan.Slice(0, idxOfNewline));
                vsb.Dispose();
            }

            char matchedChar = charBufferSpan[idxOfNewline];
            _charPos += idxOfNewline + 1;

            // If we found '\r', consume any immediately following '\n'.
            if (matchedChar == '\r')
            {
                if (_charPos < _charLen || ReadBuffer() > 0)
                {
                    if (_charBuffer[_charPos] == '\n')
                    {
                        _charPos++;
                    }
                }
            }

            return retVal;
        }

        // We didn't find '\r' or '\n'. Add it to the StringBuilder
        // and loop until we reach a newline or EOF.

        vsb.Append(charBufferSpan);
    } while (ReadBuffer() > 0);

    return vsb.ToString();
}

繼續追進 ReadBuffer()，等待輸入的過程來自 _stream.Read()，而實測：按下 Ctrl-C 或 Ctrl-Z 也會結束 .Read() 等待，但與直接按 Enter 結束的差異在於前者傳回的 _byteLen == 0，而後者 _byteLen == 2，_byteBuffer 內的資料則為 \r 及 \n：

internal virtual int ReadBuffer()
{
    _charLen = 0;
    _charPos = 0;

    if (!_checkPreamble)
    {
        _byteLen = 0;
    }

    bool eofReached = false;

    do
    {
        if (_checkPreamble)
        {
            Debug.Assert(_bytePos <= _encoding.Preamble.Length, "possible bug in _compressPreamble.  Are two threads using this StreamReader at the same time?");
            int len = _stream.Read(_byteBuffer, _bytePos, _byteBuffer.Length - _bytePos);
            Debug.Assert(len >= 0, "Stream.Read returned a negative number!  This is a bug in your stream class.");

            if (len == 0)
            {
                eofReached = true;
                break;
            }

            _byteLen += len;
        }
        else
        {
            Debug.Assert(_bytePos == 0, "bytePos can be non zero only when we are trying to _checkPreamble.  Are two threads using this StreamReader at the same time?");
            // **** 在這裡等待使用者輸入
            _byteLen = _stream.Read(_byteBuffer, 0, _byteBuffer.Length);
            Debug.Assert(_byteLen >= 0, "Stream.Read returned a negative number!  This is a bug in your stream class.");
            // 按下 Ctrl-C 或 Ctrl-Z 時也會到這行，但 _byteLen == 0 (按 Enter 的話 _byteLen == 2, 內容為 byte[] { '\r', '\n' })
            if (_byteLen == 0)
            {
                eofReached = true;
                break;
            }
        }

        // _isBlocked == whether we read fewer bytes than we asked for.
        // Note we must check it here because CompressBuffer or
        // DetectEncoding will change byteLen.
        _isBlocked = (_byteLen < _byteBuffer.Length);

        // Check for preamble before detect encoding. This is not to override the
        // user supplied Encoding for the one we implicitly detect. The user could
        // customize the encoding which we will loose, such as ThrowOnError on UTF8
        if (IsPreamble())
        {
            continue;
        }

        // If we're supposed to detect the encoding and haven't done so yet,
        // do it.  Note this may need to be called more than once.
        if (_detectEncoding && _byteLen >= 2)
        {
            DetectEncoding();
        }

        Debug.Assert(_charPos == 0 && _charLen == 0, "We shouldn't be trying to decode more data if we made progress in an earlier iteration.");
        _charLen = _decoder.GetChars(_byteBuffer, 0, _byteLen, _charBuffer, 0, flush: false);
    } while (_charLen == 0);

    if (eofReached)
    {
        // EOF has been reached - perform final flush.
        // We need to reset _bytePos and _byteLen just in case we hadn't
        // finished processing the preamble before we reached EOF.

        Debug.Assert(_charPos == 0 && _charLen == 0, "We shouldn't be looking for EOF unless we have an empty char buffer.");
        _charLen = _decoder.GetChars(_byteBuffer, 0, _byteLen, _charBuffer, 0, flush: true);
        _bytePos = 0;
        _byteLen = 0;
    }

    return _charLen;
}

追進 _stream.Read() 會來到 System.ConsolePal.WindowsConsoleStream.ReadFileNative()，這段已抵達 Unamanged 世界，再下去是作業系統 kernel32.dll 的 ReadFile() API。

// P/Invoke wrappers for writing to and from a file, nearly identical
// to the ones on FileStream.  These are duplicated to save startup/hello
// world working set and to avoid requiring a reference to the
// System.IO.FileSystem contract.

private static unsafe int ReadFileNative(IntPtr hFile, Span<byte> buffer, bool isPipe, out int bytesRead, bool useFileAPIs)
{
    if (buffer.IsEmpty)
    {
        bytesRead = 0;
        return Interop.Errors.ERROR_SUCCESS;
    }

    bool readSuccess;
    fixed (byte* p = buffer)
    {
        if (useFileAPIs)
        {
            // **** 靠這段讀取使用者輸入，背後是 kernel32.dll 的 ReadFile API，
            readSuccess = (0 != Interop.Kernel32.ReadFile(hFile, p, buffer.Length, out bytesRead, IntPtr.Zero));
        }
        else
        {
            // If the code page could be Unicode, we should use ReadConsole instead, e.g.
            int charsRead;
            readSuccess = Interop.Kernel32.ReadConsole(hFile, p, buffer.Length / BytesPerWChar, out charsRead, IntPtr.Zero);
            bytesRead = charsRead * BytesPerWChar;
        }
    }
    // **** 實測按 Ctrl-C 時，readSuccess == true
    if (readSuccess)
        return Interop.Errors.ERROR_SUCCESS;

    // For pipes that are closing or broken, just stop.
    // (E.g. ERROR_NO_DATA ("pipe is being closed") is returned when we write to a console that is closing;
    // ERROR_BROKEN_PIPE ("pipe was closed") is returned when stdin was closed, which is not an error, but EOF.)
    int errorCode = Marshal.GetLastPInvokeError();
    if (errorCode == Interop.Errors.ERROR_NO_DATA || errorCode == Interop.Errors.ERROR_BROKEN_PIPE)
        return Interop.Errors.ERROR_SUCCESS;
    return errorCode;
}
            
internal static unsafe partial class Interop
{
    internal static unsafe partial class Kernel32
    {
        [global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.Interop.LibraryImportGenerator", "8.0.10.26715")]
        internal static unsafe partial int ReadFile(nint handle, byte* bytes, int numBytesToRead, out int numBytesRead, nint mustBeZero)
        {
            int __lastError;
            global::System.Runtime.CompilerServices.Unsafe.SkipInit(out numBytesRead);
            int __retVal;
            // Pin - Pin data in preparation for calling the P/Invoke.
            fixed (int* __numBytesRead_native = &numBytesRead)
            {
                global::System.Runtime.InteropServices.Marshal.SetLastSystemError(0);
                __retVal = __PInvoke(handle, bytes, numBytesToRead, __numBytesRead_native, mustBeZero);
                __lastError = global::System.Runtime.InteropServices.Marshal.GetLastSystemError();
            }

            global::System.Runtime.InteropServices.Marshal.SetLastPInvokeError(__lastError);
            return __retVal;
            // Local P/Invoke
            [global::System.Runtime.InteropServices.DllImportAttribute("kernel32.dll", EntryPoint = "ReadFile", ExactSpelling = true)]
            static extern unsafe int __PInvoke(nint __handle_native, byte* __bytes_native, int __numBytesToRead_native, int* __numBytesRead_native, nint __mustBeZero_native);
        }
    }
}            

至此可獲得結論：ReadLine() 是用作業系統 ReadFile() API 概念讀取使用者從鍵盤輸入的內容，當按下 Ctrl-C 或 Ctrl-Z 時，等同於讀取到檔案結尾；用 StreamReader.ReadLine() 讀取實體檔案時，讀到檔案結尾會傳回 null，可用於判斷已無資料。同理，若我們不希望 ReadLine() 在按 Ctrl-C 後繼續執行，在偵測結果為 null 時結束作業即可。

修改程式如下，顯示 ReadLine() 讀取到的內容：

using System.Text;

Console.WriteLine("Before ReadLine()");
Console.Write("Enter something: ");
var line = Console.ReadLine();
Console.WriteLine($"line = {(line == null ? "null" : 
    line == string.Empty ? "string.Empty" :
    BitConverter.ToString(Encoding.UTF8.GetBytes(line)))}");
if (line == null) return;
Console.WriteLine("After ReadLine()");

測試 1 - 3 為按下 Ctrl-C 的反應，4 為 Ctrl-Z，5 為直接按 Enter。如此，就可以成功避免 ReadLine() 後方的 Console.WriteLine() 在按 Ctrl-C 後執行。

至此，終於可以宣告全案偵破，收工。

This blog post explores a peculiar behavior in .NET Console applications when pressing Ctrl-C during Console.ReadLine(). I delves into the .NET source code to explain why ReadLine() continues execution after Ctrl-C and provides a workaround to properly handle this scenario.