Not detecting closed connections

[Qix-]

Hey, first of all, thank you so much for publishing this. It's a huge help.

I have a TCP server running that will accept QEMU connections locally. I'm passing it to a dedicated Tokio thread and will shuttle messages to and from a TUI to help me debug a kernel I'm working on.

Details

use tokio::{net::TcpListener, sync::mpsc::Sender};

pub enum Event {
	Online,
	Offline,
}

pub fn start_monitor_daemon(config: crate::Config, sender: Sender<Event>) {
	std::thread::spawn(move || {
		tokio::runtime::Runtime::new()
			.unwrap()
			.block_on(run_monitor(config, sender));
		panic!("monitor thread exited!");
	});
}

async fn run_monitor(config: crate::Config, sender: Sender<Event>) {
	let listener = TcpListener::bind(("0.0.0.0", config.port)).await.unwrap();
	loop {
		sender.send(Event::Offline).await.unwrap();
		let Ok((socket, _)) = listener.accept().await else {
			continue;
		};
		sender.send(Event::Online).await.unwrap();
		println!("got connection");

		let qmp_negotiation = qapi::futures::QmpStreamTokio::open(socket).await.unwrap();
		println!("negotiation...");
		let mut qmp = qmp_negotiation.negotiate().await.unwrap();
		println!("negotiated");

		// loop and sleep for 5 seconds each time
		loop {
			let status = match qmp.execute(qapi::qmp::query_status {}).await {
				Ok(status) => status,
				Err(err) => {
					println!("error: {:#?}", err);
					break;
				}
			};
			println!("status: {status:#?}");

			tokio::time::sleep(tokio::time::Duration::from_secs(5)).await;
		}
	}
}

This so far works. However, when the remote QEMU instance is killed, the connection should close but for some reason it doesn't ever register here (the println!("error: {:#?}", err); line is never hit). For some reason, the library isn't handling closed connections appropriately.

Is there a reason for this? Or is this a bug? I'll try to investigate a bit to see if I can't figure it out myself, but figured I'd post here either way.

Thanks again for all the work on this.

[arcnmx]

I haven't had a chance to investigate yet but you might want to check if it's related to the QMP event loop. If you're not simultaneously polling for events in another future, it might help to spawn its poller in the background. The async fn execute() you're using handles this in a kind of impromptu way but there might be a problem with it...