Is std::mem::forget tokio::runtime::EnterGuard a good practice?

I encountered the following scenario:

  1. Some logic needs to fire tokio::spawn and related runtime functionalities, and then basically forget it.
  2. These logic often executes in a rayon threadpool
  3. Explicitly passing tokio::runtime::Handle around will damage other interface designs
  4. Therefore, it is better to pave all rayon threads during their initialization with tokio contexts.

In order to pave rayon threads, I can only think of calling tokio::runtime::Runtime::enter and then std::mem::forget the tokio::runtime::EnterGuard. Basically,

    rayon_threadpool.broadcast(|_| {
        let _guard = tokio_runtime.enter();
        std::mem::forget(_guard);
    });

Then the rayon worker threads can fire as many tokio functions in a non-blocking manner, as long as they are alive.

Questions:

  1. Is it even a recommended pattern?
  2. If rayon threadpool is shut down, does the leaked EnterGuard affect tokio runtime? We can safely assume the shut down is rare and is not rapidly leaking stuff.

As you pointed out, that's a memory leak. It may be untenable for a long-lived process, especially if it happens often or has the potential to happen often because the leak occurs in a public API. There are no correctness issues with leaking the guard, however.

Avoiding the need to pass a Handle is a matter of using static or scoped references that the thread pool has access to. Static if the tokio runtime is shared application-wide, or scoped if different thread pools need to use their own runtimes. Something like that should work [1].


  1. Tokio itself uses thread-locals for setting the current runtime context. ↩ī¸Ž

2 Likes

If you're creating a rayon thread pool explicitly, you can use ThreadPoolBuilder::spawn_handler() to provide a thread-spawning function that does the enter() without forgetting anything.

3 Likes

I overlooked the spawn_handler function. Constructing the rayon threadpool explicitly is indeed better in my scenario. This solved my problem.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.