Pulling USB out is not detected and eats 100% CPU

[krant]

Steps to reproduce

• Run basic_serial example and enter port name of plugged-in device
• Wait for console to calm down and pull the USB out
• Observe example loop is still running, console is clean, 1 CPU core is 100% utilized

Possible reason

This line is getting executed endlessly:

rust/src/connections/handlers.rs

Line 60 in 923d2b7

Ok(0) => continue,

If I return an error here the example starts to work, but I'm not sure it will not break something else.

[canardleteer]

Confirming I can reproduce on my end in Linux.

One interesting thing I noticed, is that this happens even with the timeout set here:

rust/src/utils_internal.rs

Lines 115 to 117 in e77d168

	let builder = tokio_serial::new(port_name.clone(), baud_rate.unwrap_or(DEFAULT_SERIAL_BAUD))
	.flow_control(tokio_serial::FlowControl::Software)
	.timeout(Duration::from_millis(10));

• This appears to be a bug in tokio-serial (at least for FreeBSD): On FreeBSD tokio-serial seems not to notice, that port is (physically) removed during wait for inbound data berkowski/tokio-serial#56
• All the way at the bottom of the stack, serialport does offer semantics for this, NoDevice in bytes_to_read. ... but my best guess is they aren't percolating up to the stream's error, and just an Ok(0) is returned.

I'm not sure it will not break something else.

@krant - Me either. start_read_handler is sufficiently generic enough to make it an unsafe bet.

I didn't have time to look much deeper into the chain of tokio-serial -> mio-serial -> serialport.

I have however, confirmed that changing the line to:

   Ok(0) => { tokio::time::sleep(Duration::from_millis(5)).await; continue},

Will reduce the CPU usage down from 100%, which might be enough to make it tolerable in the meantime, until someone gets a chance to dig deeper.

[krant]

tokio-serial example handles the pulling correctly:

cargo run --features="rt codec" --example serial_println -- /dev/ttyACM0
[LOG DATA]
## Pull out USB
[PROGRAM EXITS]

[powturns]

I seem to be able to reproduce this using the tcp_stream as well if the socket is closed.