maybe better

[songwei163]

tokio::select! { _ = recv_thread => (), _ = write_thread => (), _ = signal_thread => connection.close(0u32.into(), b"signal HUP"), }
如果将这些不同的处理逻辑拆分到不同的tokio::spawn中可能会更好，读写分离；放到一个spawn中，select中的某个匹配臂阻塞的话可能会导致其他匹配臂无法得到执行。recv或者send 动作可能需要添加time-out。

[oowl]

Good catch, PR welcome.

[JyJyJcr]

This won't happen. Since we use tokio in async ≃ non-blocking mode, all of IO calls are internally switched in short time, no need to worry about that recv or send thread block the whole process. What we should avoid is synchronous heavy tasks.

[songwei163]

What I'm saying is that the business side is better off encapsulating its own timeout control than just relying on quinn's timeout disconnection if the network is bad

[JyJyJcr]

I understood the purpose of setting own timeout, but we can directly adjust quinn's timeout here, which I think is the better way than adding another timeout.

quicssh-rs/src/client.rs

Line 71 in 4887a92

transport_config.max_idle_timeout(Some(VarInt::from_u32(60_000).into()));

An cmdline option will be suited for the interface, like ping's -t option.