"i'm in need of some suggestions..." <- > <@rursprung:matrix.org> i'm in need of some suggestions for an `std` async problem (using `tokio`): > > * i have a struct (let's call it `Connection`) which wraps external tools needed to talk to my embedded device from linux (i can't change the communication channel; launching these things from rust is done to simplify everything so that i don't need an external script to orchestrate the startup) > * i need a way to offer `wait_closed` on my connection (which should never close unless things go wrong) > * in it i need to `await` a process (`tokio::process::Child::wait`) > * in it i need to `await` a `tokio::JoinHandle` > * i use `select!` for these two since i don't know which one will happen (hopefully neither) > * i need a way to terminate these two on `Drop` of my struct holding them > * i have a struct (let's call it `Device`) which starts the connection and offers high-level APIs to talk to the device and also offers a `wait_closed` (just forwarding to the underlying one) > * i need a way to `select!` on my `wait_closed` as well as some `run` action which both need the same struct to talk to the device > > my `wait_closed` on `Connection` needs to take `&mut self` since `Child::wait` takes `&mut self` and i also want to wrap the `Child` & `JoinHandle` in an `Option` to ensure that i don't try to remove them again in my `Drop` impl (that might cause problems otherwise?). > > but due to the `&mut self` i cannot pass the same `Device` also into my `run` function in the `select!`. > > i tried various just wrapping my `Connection` in `Device` in a `RefCell` just to hit [`clippy::await_holding_refcell_ref`](https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_refcell_ref) (which i wasn't aware of yet). > > so now i'm really unsure what approach i should choose? > > i took the `wait_closed` idea from `postcard-rpc`, but it manages with just `&self` and uses an internal `Stopper` (using `Arc` underneath and i really didn't see how that's working 🙁 > > what approach would you suggest to get out of this conundrum? If you can stomach the platform, Tokio has a discord where the devs hang out. Be prepared for high latency in replies thou