Should smol::Timer work inside a tokio runtime?

[mitchmindtree]

Hi!

I'm currently experimenting by attempting to run futures created with smol in other async runtimes.

In this case I'm having a go at writing to an Async<UdpSocket> once per second. I've noticed that writing to the Async<UdpSocket> does seem to work nicely. However, the Timer future does not seem to make progress in the tokio runtime. If I instead create my "once-per-second" stream using futures-timer, everything seems to work as expected.

Is this expected behaviour? I'm still quite new to async Rust so feel free to tell me if I'm being silly! Otherwise let me know if you'd like me to assemble a small test case and I'll put something together next time I get the chance.

Edit: I should note that I did try enabling the "tokio02" feature but it didn't seem to have an effect - I guess because this feature is aimed running tokio futures inside a smol runtime and not the other way around?

Edit 2: I just tested with async-std instead of tokio and in this case it seems the smol::Timer does work.

[mitchmindtree]

After doing some more digging it seems quite clear to me that smol::Timer should not be expected to work with a tokio runtime seeing as it is the smol reactor that drives the smol::Timer. I assume it works with the async-std runtime because parts of the runtime (async_task) are shared with smol?

Sorry for the noise! I'm doing these experiments with the aim of better learning how to write an async library, i.e. what aspects of each of these async crates are portable and what are not. The Async type seems like magic sauce for this case, providing the ability to use a std socket/listener/stream in a manner that is compatible with not only smol's runtime but the other popular runtimes too. Is that the case, or am I perhaps misunderstanding the result I'm seeing?

[ghost]

Only tokio has the concept of a runtime context, which you enter using Runtime::block_on(), Runtime::enter(), or spawn(). When we're inside the runtime context, that just means some tokio's thread-locals are set up. Then, tokio's timer will access those thread-locals on every use and panic if they are not set up.

In contrast to that, async-std and smol have a single global context, which means all timers and I/O handles are registered in some kind of global variable. When a timer is used, it will simply register itself in that global variable, whereas tokio's timer will access the thread-local to figure out where to register itself. Therefore, async-std's and smol's timers never panic because they're always and everywhere inside the runtime context.

The difference between async-std and smol is in how the reactor (I/O and timers) is driven. In async-std there's a lazily initialized global executor thread pool that drives the reactor. As soon as you create a timer, or access the runtime in any way, it will be initialized and spin up the thread pool. So everything just works.

Now, smol chose to not spin up a thread pool for you. Instead, you need to start at least one executor using run(), which will drive I/O and timers. So, smol's timers will work as long as there is at least one thread calling run(). Simple as that.

You could just do thread::spawn(|| smol::run(future::pending::<()>())) and call it a day. Or, wrap the whole main function inside smol::run().