Is there any way to perform a POST request on drop?

[stevepryde]

I have a library (thirtyfour) for working with selenium/webdriver and it needs to be able to send a web request to automatically close the browser session when the WebDriver struct is dropped.

However when I try to perform a request on drop it deadlocks when using the single-threaded tokio executor.

Things I've tried so far:

• creating a new runtime and doing block_on(). Tokio doesn't allow this.
• using futures::executor::block_on() - deadlock
• using async_std::task::block_on() - deadlock

Is there any possible way to make a POST request on drop, with reqwest, running under tokio's basic scheduler?

Simple example:

pub struct MyStruct {}

impl Drop for MyStruct {
    fn drop(&mut self) {
        // is there any way to make an async request here using reqwest?
    }
}

[davidpdrsn]

Async drop isn't directly supported at the moment unfortunately.

One workaround I've used in the past is spawning a task that receives on a oneshot channel, which MyStruct sends to in its destructor. Something like:

use tokio::sync::oneshot;

async fn some_function() {
    let (tx, mut rx) = oneshot::channel();

    let my_struct = MyStruct { tx: Some(tx) };

    tokio::spawn(async move {
        let msg = rx.await;
        // `my_struct` was dropped
    });
}

struct Msg;

struct MyStruct {
    tx: Option<oneshot::Sender<Msg>>,
}

impl Drop for MyStruct {
    fn drop(&mut self) {
        self.tx.take().expect("dropped twice").send(Msg);
    }
}

The task could be seen as a kind of "actor".

[stevepryde]

I've tried this approach before but from memory the spawned task may not actually run if the program exits shortly after. That indeterminacy / inconsistency makes that approach not ideal.

I'm currently using futures::executor::block_on() which actually works fine with the multi threaded runtime but not the basic one.

Anyway, it seems that you've answered my question. Thanks

[Darksonn]

I'm currently using futures::executor::block_on() which actually works fine with the multi threaded runtime but not the basic one.

It only works if you have fewer destructors doing this than the runtime has threads because each destructor would be taking up an entire runtime thread by blocking it. It's a pretty bad idea to do that.

[stevepryde]

Yeah it did seem pretty nasty. But it works so well 😂

Meanwhile if it spawns a task, how does the calling code keep Tokio alive until that task completes? If the program exits before that, the browser window stays open. It seems the most reliable path is not to even attempt to auto close, and to require the caller to explicitly close the session. That's already possible (and will consume the object) but just easily forgotten.

[Darksonn]

Honestly, the correct answer is to not shut down the runtime until you have finished doing everything you wanted to do. Async drop is simply not supported by Rust.

[stevepryde]

I understand that, but if the webdriver instance gets dropped and a task is spawned, is there even a way to tell Tokio to wait until that task completes? My understanding is that because the join handle is unable to be known, there's not really any way to know when that task completed.

[Darksonn]

The Rust language does not support asynchronous code in destructors. Tokio's block_on panics to protect you from the deadlock you got with other runtimes. You will need to either run the request before the destructor, or to have the destructor send a message to another part of your code which can then send the request.

The simplest option is probably to just spawn a task:

pub struct MyStruct {}

impl Drop for MyStruct {
    fn drop(&mut self) {
        tokio::spawn(async move {
            // async code can go here
        });
    }
}