Xinye Tao

Ping @youjiali1995

Here's another one: ```rust use tokio::sync::{mpsc, oneshot}; #[tokio::main] async fn main() { let (tx, rx) = mpsc::channel(1); let permit = tx.reserve().await.unwrap(); let (inner_tx, mut inner_rx) = oneshot::channel::(); drop(rx); permit.send(inner_tx); //...

> If the receiver is dropped in parallel with that, I believe the value may not get dropped. Right, I didn't think it through. I can only see two ways...

> I considered using a spin_loop inside Drop, but that could easily introduce new deadlock scenarios. Yes, this is the option b I mentioned. Wait in dtor is simply too...

> I'm considering closing this as wontfix. Make sense to me. The document needs some work though. The case in https://github.com/tokio-rs/tokio/issues/7714#issuecomment-3471080944 causes a real hang in our application.

I took another look and it seems I was mistaken earlier. The problematic client call future is deep in our stack and was detached to the runtime. To be more...

Assuming from the tag the code is welcome? It's very noisy TBH, but here goes: https://gist.github.com/tabokie/84728599bbb475fc947a53b84d37d04e , failing at fragment_resolver.rs:L729