Console selection stops application

Question

I'm running a socket server on my server and I woke up to numerous messages about its inaccessibility. It turns out that before I went to bed, I had highlighted an IP address in the window and forgot to hit Enter to resume the process.

This is how I disable selection in the console, now, but I still want to be able to select without the application pausing.

    #region Disable Quick-Edit Mode
    [DllImport("kernel32.dll")]
    static extern bool SetConsoleMode(IntPtr hConsoleHandle, int mode);

    [DllImport("kernel32.dll")]
    static extern bool GetConsoleMode(IntPtr hConsoleHandle, out int mode);

    [DllImport("kernel32.dll")]
    static extern IntPtr GetStdHandle(int handle);

    const int STD_INPUT_HANDLE = -10;
    const int ENABLE_EXTENDED_FLAGS = 0x80;

    public static void DisableQuickEditMode()
    {
        int mode;
        IntPtr handle = GetStdHandle(STD_INPUT_HANDLE);
        GetConsoleMode(handle, out mode);
        mode |= ENABLE_EXTENDED_FLAGS;
        SetConsoleMode(handle, mode);
        mode &= ~ENABLE_QUICK_EDIT;
        SetConsoleMode(handle, mode);
    }

I really don't want to go back to the Legacy Mode of Command Prompt, because it really does help to have these new features (especially for devs), but I need to find a way to prevent the application from stopping when I pause the console. What's interesting is that when I hit Enter this morning, all of the connections that had been attempted were processed, and then after they were processed, they were dropped. Which makes me wonder if, perhaps, I'm writing the application wrong; that I need to have a "Console" thread and a "Server" thread. But I'm not sure that could even make a difference.

Answer 1

When in selection mode, any thread in the Windows console will block when writing stdout or stderr. Doesn't matter which thread.

You could separate out the console writes from the server operations and make sure the server threads never write to the console, but then you introduce additional thread management and message queueing concerns.

You could do what most people do: Use log files. If you don't want to build file writing into the application, just pipe stdout and stderr to a file and use some Windows equivalent of tail to monitor the file (or a text editor like Sublime which automatically monitors open files).

server.exe > server.log 2>&1

To clarify: 2>&1 indicates that stderr (file handle 2) should be "merged into" stdout (file handle 1).