在Rust中为Future实现Drop及相关技术问题咨询

安全阿岳

2026-8-6

Rust异步Future取消与清理的实现疑问解答

我有一个异步函数my_async_fn，需要支持取消操作（允许调用者使用tokio::time::timeout或futures::future::select来取消该函数），同时无论该函数是否被取消，都必须执行清理操作（删除my_async_fn写入文件的部分内容）。为此实现了一个OnDropFuture，它将轮询转发给内部Future，并通过调用传入的FnMut来实现Drop trait，代码如下：

trait OnDropFutureExt
where
    Self: Future + Sized,
{
    fn on_drop<D: FnMut()>(self, on_drop: D) -> OnDropFuture<Self, D>;
}
impl<F: Future> OnDropFutureExt for F {
    fn on_drop<D: FnMut()>(self, on_drop: D) -> OnDropFuture<Self, D> {
        OnDropFuture {
            inner: self,
            on_drop,
        }
    }
}


struct OnDropFuture<F: Future, D: FnMut()> {
    inner: F,
    on_drop: D,
}
impl<F: Future, D: FnMut()> OnDropFuture<F, D> {
    // See: https://doc.rust-lang.org/std/pin/#pinning-is-structural-for-field
    fn get_mut_inner(self: Pin<&mut Self>) -> Pin<&mut F> {
        unsafe { self.map_unchecked_mut(|s| &mut s.inner) }
    }

    // See: https://doc.rust-lang.org/std/pin/#pinning-is-not-structural-for-field
    fn get_mut_on_drop(self: Pin<&mut Self>) -> &mut D {
        unsafe { &mut self.get_unchecked_mut().on_drop }
    }
}
impl<F: Future, D: FnMut()> Future for OnDropFuture<F, D> {
    type Output = F::Output;

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<F::Output> {
        self.get_mut_inner().poll(cx)
    }
}
impl<F: Future, D: FnMut()> Drop for OnDropFuture<F, D> {
    fn drop(&mut self) {
        // See: https://doc.rust-lang.org/std/pin/#drop-implementation
        inner_drop(unsafe { Pin::new_unchecked(self) });
        fn inner_drop<F: Future, D: FnMut()>(this: Pin<&mut OnDropFuture<F, D>>) {
            this.get_mut_on_drop()();
        }
    }
}

使用方式如下：

my_async_fn().on_drop(|| clean_up_file(&file_path)).await?;

技术疑问与解答

1. 清理操作的错误传播问题

目前只能记录清理失败日志后继续执行，更优方案包括：

合并结果返回：修改OnDropFuture的输出类型，将主任务结果与清理结果合并，比如返回Result<(F::Output, Result<(), CleanupError>), F::Error>。需要在Future的poll方法中跟踪清理状态，或在Drop中存储清理错误，待主任务完成后一并返回。
异步清理+错误传递：如果清理是IO密集型，用tokio::spawn_blocking异步执行清理，通过Arc<Mutex<Option<CleanupError>>>将错误传递给调用者，调用者后续可检查该错误。
日志+监控告警：如果清理失败不影响主业务流程，日志记录是最常用方案，可配合监控系统对清理失败事件告警，确保及时发现问题。

2. on_drop panic与UnwindSafe处理

Rust中若Drop trait内发生panic，且当前已有panic在展开，程序会直接终止，因此必须确保on_drop不会panic，或用std::panic::catch_unwind捕获。
对于可变引用的UnwindSafe问题，可以将on_drop包装在std::panic::AssertUnwindSafe中，它是标记trait，强制编译器认为值是unwind安全的。修改OnDropFuture的on_drop字段为AssertUnwindSafe<D>，调用时用AssertUnwindSafe(on_drop)包裹即可。需自行确保on_drop在unwind时不会导致资源泄露或未定义行为。

3. 同步清理与block_on的选择

短耗时清理：若清理操作耗时极短（如删除小文件、修改元数据），同步实现完全可行，不会阻塞异步runtime的工作线程。
block_on的问题：futures::executor::block_on会阻塞当前线程直到异步操作完成，无法让其他任务运行，不适合在异步工作线程中使用。
长耗时/异步清理：若清理操作耗时较长或本身是异步IO，推荐用tokio::spawn_blocking（针对Tokio runtime）将同步清理提交到阻塞线程池，避免阻塞异步工作线程；若用异步清理函数，可结合Tokio的block_in_place，但需注意不能嵌套调用且runtime需支持该功能。

4. FnOnce类型的实现安全性

将on_drop改为ManuallyDrop<D>并实现Drop的方式是安全的，需注意以下几点：

ManuallyDrop::take的unsafe操作：在Drop方法中，OnDropFuture即将被销毁，取出on_drop后不会再访问原字段，因此不会触发未定义行为。
需修改OnDropFuture的定义，将on_drop字段改为ManuallyDrop<D>，并调整get_mut_on_drop方法返回&mut ManuallyDrop<D>。
该实现确保FnOnce()只被调用一次，符合需求。相关技术讨论也认可这种实现方式的安全性，只要保证take后不再访问原字段即可。

内容的提问来源于stack exchange，提问作者Adrodoc