3 ms·
> My #1 complaint about Rust is that leaking a future is safe. Do you mean futures that aren't polled to completion, tasks that aren't joined, or literal memor
by duped 3y ago
> My #1 complaint about Rust is that leaking a future is safe.
Do you mean futures that aren't polled to completion, tasks that aren't joined, or literal memory leaks that happen to own futures?
- hedora 3y agoThe first and third thing. (They're basically equivalent.) You can start polling then do std::mem::forget on the future. At that point, the borrow checker thinks the future no longer exists. So, it is unsound to pass a reference with a bounded lifetime into a future (which is why you need all the references to be 'static if you pass something into a spawn, or you need to spray Arc everywhere).
- duped 3y agoThey're very different, because a future may be dropped before it is polled to completion (aka, cancellation). If you leak it, then the drop handlers are not called, and this can affect program correctness. It is not unsound for a future to own a reference (in fact it's super common - how else would asnc methods work?). If you leak the future, it can't be polled and it can't be dropped, so any references will never be dereferenced. But also that's a pretty contrived example. Like you could call std::mem::forget on a future that owns a tokio::sync::MutexGuard and then you'd have some problems with deadlock... but that's not an async issue, it's always incorrect to leak an RAII guard (same as if you leaked std::sync::MutexGuard) tokio::spawn has a 'static bound because it simplifies things, not because there's some fundamental limitation of futures owning references.