mlsvrts

I think switching to overlapped io on Windows is the right choice, but we need to be careful about (and probably expose) the COMMTIMEOUTs. It's confusing and painful to get...

@ma6254 Thanks for reporting this; it looks like we're using the ANSI version of the windows API, which is probably why this breaks. Can you try this patched branch and...

@ma6254 Actually, this may have been an issue with my patch! I checked again, and the device manufacturer and "friendly name" are read from the registry keys -- this was...

After *some review*, I have determined that the read size is set by the `NamedPipe` from `mio`. See: https://github.com/tokio-rs/mio/blob/c9e33691034be4df491fed7b24b5eeb4d20f8d7d/src/sys/windows/named_pipe.rs#L805 And behold, if I modify this to `.get(1)`: ``` C:\>.\build\async-serial-test.exe COM1...

@estokes No problem, maybe this will help some other poor soul someday. To that end, I have one additional note for anyone (like me) who is attempting to implement a...

@Thomasdezeeuw Yes, I agree that's a correct interpretation. Actually the performance would probably be better that way as well; in the case of USB to Serial adapters, for instance, I...

@Thomasdezeeuw Yes, I think that's the most straightforward solution; `mio-serial` and other libraries should be able to use that to control the buffering characteristics for read requests. In the default...

I'm not able to easily pull and test this anymore, but these changes should support the composite CDC-ACM use-case, so it looks good to me, thanks!

Does `bytes_to_read` indicate that there are 52 bytes available when you read? Do you always get the same number of bytes from the first read request, or does it vary?...

@craigkai Windows COMMTIMEOUTS are _extremely cursed_, and I'm nearly certain they're at fault here. On Windows, if you try to read 'n' bytes from a serial port no data will...