TTYPort::read doesn't respect timeout
#7
Comments
danielstuart14
added a commit
to danielstuart14/serialport-rs
that referenced
this issue
May 24, 2024
In some cases, when a underlying error happens to a TTY port between poll::wait_read_fd and unistd::read, the read function would hang waiting for some data that is never received. This commit sets the port to non-canonical mode, with VMIN = VTIME = 0. With this change, it has the effect of making reads non-blocking, returning right away. The timeout behaviour is maintained, as prior to reading we call unix::poll through poll::wait_read_fd. Fixes: serialport#7
danielstuart14
added a commit
to danielstuart14/serialport-rs
that referenced
this issue
May 24, 2024
In some cases, when a underlying error happens to a TTY port between poll::wait_read_fd and unistd::read, the read function would hang waiting for some data that is never received. This commit sets the port to non-canonical mode, with VMIN = VTIME = 0. With this change, it has the effect of making reads non-blocking, returning right away. The timeout behaviour is maintained, as prior to reading we call unix::poll through poll::wait_read_fd. Fixes: serialport#7
danielstuart14
added a commit
to danielstuart14/serialport-rs
that referenced
this issue
May 24, 2024
In some cases, when a underlying error happens to a TTY port between poll::wait_read_fd and unistd::read, the read function would hang waiting for some data that is never received. This commit sets the port to non-canonical mode, with VMIN = VTIME = 0. With this change, it has the effect of making reads non-blocking, returning right away. The timeout behaviour is maintained, as prior to reading we call unix::poll through poll::wait_read_fd. Fixes: serialport#7
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue was migrated from GitLab. The original issue can be found here:
https://gitlab.com/susurrus/serialport-rs/-/issues/74
I have an application that sometimes just hangs, seemingly forever. I've tracked the problem down to
TTYPort::read.I'm setting a timeout on the port and I know this works, as the application experiences timeouts quite regularly. Despite this, the call to
readdoesn't return. I've added some debug output, and tracked the problem to the second call inread.super::poll::wait_read_fdreturns,nix::unistd::readdoesn't.The serial port I'm using is connected through USB to a microcontroller, and something really weird is going on over there (longstanding USB-related bug that I wasn't able to track down so far). I'm not surprised that this is causing weird behavior on the host side. However, it would be great, if serialport-rs could respect the timeout setting under such circumstances, if at all possible.
The text was updated successfully, but these errors were encountered: