Why is tokio::task::block_in_place() a bad idea? + other async questions

[drewlwhitney]

Hello!

Main Question

I was reading the docs for slint::spawn_local() and I noticed it says

The use of #[tokio::main] is not recommended

near the bottom.

Why is it a bad idea? My thought would be to use #[tokio::main] with tokio::task::block_in_place() for slint::run_event_loop(). I would then be able to run tokio futures from anywhere in the application, right? Even in something like slint::spawn_local()?

I like the idea of this because I would be able to have multi-threaded async stuff without having to think about it. I could just tokio::spawn() things when needed and interact with the GUI through slint::invoke_from_event_loop().

Am I missing something here?

Side Questions

• Why does Slint (and seemingly many other async applications) not use tokio as a runtime directly? Is it a desire not to take on extra dependencies?

• Is Slint's runtime actually async? i.e. if I call slint::spawn_local() multiple times with long-running futures, will .await actually switch between tasks?

---

Thanks!

[ogoffart]

Because #[tokio::main] starts an event loop in the main thread, but we need to also start our own (winit's) event loop. There can only be one event loop per thread.
The spawn blocking will tell tokio that this thread can no longer be used to spawn tasks.

So the #[tokio::main] will create an event loop in the bottom of the stack of the main thread, and then we use block_in_place to tell tokio to actually not use it. That means the event loop was created for nothing, it's just wasted resources.

Why does Slint (and seemingly many other async applications) not use tokio as a runtime directly?

Because we use winit, because we need an event loop that integrate with the windowing system's event loop.
And therefore we don't need tokio.

Slint's runtime actually async?

Yes it is. 100%
(You can view slint as a single threaded runtime.)
Spawn as many long-running future as you want, they will be polled when the waker is woken up. Following the design of Rust futures.

[drewlwhitney]

Main Question

Wouldn't tokio::task::block_in_place() shunt all tokio tasks into other threads, so the tokio executor wouldn't block? This is assuming I have a multi-threaded tokio runtime. My understanding is that slint can run in one non-tokio-managed thread while all the tokio stuff runs in other threads. I was able to test this on the gallery example by adding #[tokio::main], tokio::spawning some async tasks, then using tokio::task::block_in_place() to run the app. It seems to work fine. Are there other concerns with using tokio alongside slint?

Side Questions

• Mmmm understood
• Sublime!

---

Thanks!

[ogoffart]

Sure, it works fine. But it is still a pointless use of resource to create a a tokio event loop on the main thread and not using it. It's just a small waste, but waste nonetheless.

Instead, the best is to create the tokio Runtime, and enter() it (without blocking on it), without starting the event loop on the main thread.
This is exactly what the async_compat crate does and why we recommend that instead.

[drewlwhitney]

I see. I was worried the problem was with using tokio itself, but it sounds like we just want to avoid wasting resources (which I agree with). Thank you!

[sandreas]

@drewlwhitney
You can still use tokio though... This example is probably very naive (as I'm a Rust beginner), but it seems to work.

[drewlwhitney]

@sandreas perhaps it is better to explicitly create the runtime rather than using #[tokio::main]. I guess I'm more asking if it is a bad idea to use slint and tokio together. It is nice to have access to some tokio futures that are otherwise unavailable if the tokio runtime isn't running

[sandreas]

@drewlwhitney

I personally don't think that tokio is a bad idea in general. AFAIK only #[tokio:main] is discouraged.

In my sample I create a tokio runtime manually, extract the handle and operate on a clone of the handle or in case of the UI thread on the original. This seems to work fine, although I must say that using libraries that may be blocking (e.g. evdev) is a bit tricky.

Tokio might no longer switch threads when a loop is used within a tokio::spawn and results in never finishing work / deadlock. So my personal approach now is to use tokio::spawn for all crates that officially support tokio (like sea-orm) and to use std for everything else, because std creates REAL threads.

This was a very painful lesson since tokio::spawn with loop worked fine on my notebook (supporting multiple cores and threads), but compiling for a embedded device that only supports 1 core / 1 thread it did not resulting in randomly totally blocking the UI when using tokio the wrong way - only reproducible on the embedded device without debug support.

[drewlwhitney]

Yup, I'd have to be careful to only compile the app for devices with multithreading support. I'll go ahead and close this since it seems like there isn't a problem with using tokio in general.

Thanks!