Console streams are blocking on Windows

[straight-shoota]

This has been mentioned before but I don't think there's a dedicated issue for it.

The standard streams on Windows are blocking. On Unix systems, on the other hand, they are non-blocking for TTYs. It allows to continue other fibers while waiting on IO. This is particularly relevant for STDIN.

For example, the following program prints the current time and updates it every second, while pressing enter aborts.

spawn do
  loop do
    print Time.utc.to_s("%H:%M:%S\r")
    sleep 1.second
  end
end

STDIN.gets

On Windows, it doesn't print anything because STDIN.gets is blocking and the loop fiber never gets a chance to execute.

We should have the same behaviour as on Unix. I'm not sure how we can best achieve it.

• We're already detecting whether the standard streams are a console. So this information can be used.
• It might be possible that we can set blocking: false in FileDescriptor.from_stdio on Windows. This certainly requires Support asynchronous file I/O on Windows #14321 and maybe something else. We would probably have to duplicate the file descriptor as we do on Unix, in order to avoid problems with the parent process. But I'm not sure about the Windows mechanics here.
• The Win32 API also provides special functions for dealing with console handles, such as GetNumberOfConsoleInputEvents.

[HertzDevil]

IIRC Win32 console handles do not support overlapped I/O, so any kind of asynchronous capability requires threads; the standard input and output streams are not opened with FILE_FLAG_OVERLAPPED, and additional console handles opened using CreateFile do not respect that flag