Windows hardware flow control (DTR/CTS) about go-serial

[chinenual]

I still believe this is probably a bug -- Nonzero InterCharacterTimeout and non-zero MinimumReadSize is supposed to cause read to block, but what I'm actually seeing is an immediate return of the Read with n=0 and err=nil.

My workaround is to treat that condition as a "block", like this in my goroutine:

	go func () {
		var arr []byte = make([]byte,1);
		for {
			select {
			case <- readerChannelQuit:
				close(readerChannelQuit)
				close(readerChannel)
				return
			default:
				var response serialReadResponse
				var n int
				n, response.err = stream.Read(arr);
				if err != nil {
					response.data = 0
					readerChannel <- response
				} else if n == 1 {
					response.data = arr[0]
					readerChannel <- response
				} else if err == nil {
					// on windows, despite asking for blocking IO
					// the Read is returning immediately with
					// n == 0, but no error.  Sleep for a
					// while so we don't chew up infinite CPU
					time.Sleep(time.Duration(500) * time.Millisecond)
				}
			}
		}
	}()

[chinenual]

My work around (above) is not really practical. While this does emulate blocking IO, it results in SUPER SLOW reads -- apparently even when there is data on the line, I'm getting at least as many empty reads that good ones - so that 1/2 second delay is effectively happening on every byte.

Hoping someone else using the library on Windows has some insights...