Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking on write in MacOS #9

Open
bailout00 opened this issue Jun 20, 2024 · 9 comments
Open

Blocking on write in MacOS #9

bailout00 opened this issue Jun 20, 2024 · 9 comments

Comments

@bailout00
Copy link

Curious if anyone is running into this? Writing shouldn't block but it is. When writing to a pipe on MacOS or a serial port on a linux device, no issue. But during development I'm using a usbserial adapter and its blocking on port.write() and I don't understand why.

@de-vri-es
Copy link
Owner

Hey! Thank you for opening an issue.

How much data are you trying to write and how long does it block? If you send enough data to fill the kernel buffers, then it should block. So we need to figure out if this is what is happening.

@de-vri-es
Copy link
Owner

Also note that there was a bugfix recently that may be related to this: #7

So if you're not on v0.1.11, please update to make sure that is not the issue you are seeing.

@bailout00
Copy link
Author

So I did just bump to 0.1.12, now it no longer blocks but I'm seeing "Error writing command: Elapsed(())". This happens immediately and for every variation of write. Also tried multiple adapters. It does not happen when using a socat virtual port (pipe)

@bailout00
Copy link
Author

Removing the tokio layer, I get Error writing command: Kind(TimedOut) on the serial2 lib alone, mabye I should move this over there.

@de-vri-es
Copy link
Owner

Would it be possible to share your code and the details of your serial converter and the device you're trying to communicate with?

serial2-tokio doesn't enforce any tokio level timeouts at all, but Elapsed sounds like a tokio timeout.

@bailout00
Copy link
Author

You're correct, it is a tokio timeout because otherwise it will just block the thread forever. Still unsure whats causing this but if its any help, with the changes you made in .13, now it won't open a port at all:

let mut port = SerialPort::open("/dev/tty.usbserial-16485", 115200).expect("Failed to open port");

Results in:

thread 'tokio-runtime-worker' panicked at src/serial.rs:27:61:
Failed to open port: Custom { kind: Other, error: "failed to apply some or all settings" }

I've tried several USB adapters, settings, and running under sudo. Even on a very minimal app with literally only that line, I'm getting the same error. Maybe something with the USB/serial driver? I've tried every variation I have laying around with no luck.

I've also tried virtual ports just for the sake of troubleshooting, but they aren't recognized as a valid TTY:

Failed to open port: Os { code: 25, kind: Uncategorized, message: "Inappropriate ioctl for device" }

@bailout00
Copy link
Author

Just for completeness:

use serial2_tokio::SerialPort;

 fn main() {
    let mut port = SerialPort::open("/dev/tty.usbserial-14430", 115200).expect("Failed to open port");
}
thread 'main' panicked at src/main.rs:4:73:
Failed to open port: Custom { kind: Other, error: "failed to apply some or all settings" }

from lock file

[[package]]
name = "serial2-tokio"
version = "0.1.13"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e21594c39572e9a1ef73844dbb3e0499c8486cd7e7742b18d03e3c06d9208492"
dependencies = [
 "libc",
 "serial2",
 "tokio",
 "winapi",
]

I'm on an M3 running Sonoma 14.7.1, but same thing before I upgraded last week from Ventura.

@de-vri-es
Copy link
Owner

de-vri-es commented Nov 10, 2024

Ah, I think that problem was introduced with de-vri-es/serial2-rs#39. Sadly it is difficult for me to properly test on macOS, so this slipped past. There should be a fix open in de-vri-es/serial2-rs#45, but I would really like someone to verify if it works before I release it :]

/edit: ah, I see you already found that thread. Still good to know for other people reading this issue though :)

@de-vri-es
Copy link
Owner

I just released v0.1.14 with the same fixed in serial2. It should allow you to at-least open a serial port without errors again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants