Which means the corresponding input_rx got dropped before/during the input_tx.send call.
But input_rx lives inside the loop of session.rs:97 the whole time. It seems to me that the receiver never dies. However, io_task_handle represents that tokio task and will be aborted at session.rs:240:
io_task_handle.abort();
This line will kill input_rx and if unfortunately, input_tx was awaiting at that point, then the panic will be hit.
I got this "input channel closed" panic the second time:
tokio_kcp-2bd8e2d6d03e8a8d
is the commit before modification of the version string0.9.5
inCargo.toml
.Previously I though it was caused by #28. But this version of tokio_kcp has already fixed that. So it might be another freshly discovered bug.
I investigated a little bit and spot some sus behaviors in
session.rs
.First off, this line hits the panic:
Which means the corresponding
input_rx
got dropped before/during theinput_tx.send
call.But
input_rx
lives inside the loop ofsession.rs:97
the whole time. It seems to me that the receiver never dies. However,io_task_handle
represents that tokio task and will be aborted atsession.rs:240
:This line will kill
input_rx
and if unfortunately,input_tx
wasawait
ing at that point, then the panic will be hit.