3 ms·
One current gap is that async drops aren't currently a thing - you cannot do any async work to clean up a resource. I imagine Niko will point that out in the ne
by wging 5y ago
One current gap is that async drops aren't currently a thing - you cannot do any async work to clean up a resource. I imagine Niko will point that out in the next post. See also https://boats.gitlab.io/blog/post/poll-drop/ https://boats.gitlab.io/blog/post/poll-drop/
- ithkuil 5y agoI toyed a little bit with an approach to async drop; let me know what do you think https://crates.io/crates/arcy https://crates.io/crates/arcy
- leshow 5y agoNot OP, async drop isn't a thing, but you can still have a drop guard in an async function. It's not as nice as having async drop obviously, because you can't run any await-able code inside Drop, but it still works for some situations: async fn foo() { let guard = Guard; // async stuff } impl Drop for Guard { fn drop(&mut self) { // do cleanup } }
- pornel 5y agoThis is indeed a big gap for interacting with non-Rust async APIs where you can't dictate memory management strategy. However, within Rust, it rarely comes up. Probably because native Rust libraries/interfaces have no choice but design around it. If you really have to finish some work asynchronously on drop, you can spawn another task from your drop function. But most of the time I've found it's not even necessary, because you can restructure the code to separate the "abortable" part from the "must finish" part (e.g. some network protocol serializer must always terminate a message it writes, but generation of the message itself is typically done elsewhere, so you can set it up so that abort of the message-generating future doesn't abort the protocol-framing future).