Override COMMTIMEOUTS to not wake up with empty data on Windows #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The serialport crate sets ReadTotalTimeoutConstant to the specified timeout value [1], which makes the reader wake up quite often with no payload, and confuses the tokio wrapper [2] since a 0-byte read usually means EOF. [1]: https://gitlab.com/susurrus/serialport-rs/blob/2.3.0/src/windows/com.rs#L224 [2]: berkowski#7 The MSDN doc [3] is unclear how we can configure a COM port to make it behave like a socket, but I found an example on StackOverflow [4], so tried it and it just worked. Still the serial_printline.rs example printed "Read timed out!" per loop, but the whole "Read would have blocked." mess went away. And my tokio-based program worked on Windows in the same way as on Linux. [3]: https://docs.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-_commtimeouts [4]: https://stackoverflow.com/a/26007086/10435339 Since I'm not a Windows user, I can't say this is the best and most correct solution. QtSerialPort appears to set ReadIntervalTimeout to MAXDWORD, but it didn't go well. I've tested this change on VirtualBox with a pseudo serial device connected to the host's TCP socket.
|
I'm pretty much in the same boat when it comes to the windows API. From the sources you've linked I think I can understand how the solution you've found should mimic how the unix side works. I'm inclined to say if it works for you, that's good enough for now. |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The serialport crate sets ReadTotalTimeoutConstant to the specified timeout
value 1, which makes the reader wake up quite often with no payload, and
confuses the tokio wrapper 2 since a 0-byte read usually means EOF.
The MSDN doc 3 is unclear how we can configure a COM port to make it behave
like a socket, but I found an example on StackOverflow 4, so tried it and
it just worked. Still the serial_printline.rs example printed "Read timed out!"
per loop, but the whole "Read would have blocked." mess went away. And my
tokio-based program worked on Windows in the same way as on Linux.
Since I'm not a Windows user, I can't say this is the best and most correct
solution. QtSerialPort appears to set ReadIntervalTimeout to MAXDWORD, but
it didn't go well. I've tested this change on VirtualBox with a pseudo serial
device connected to the host's TCP socket.