Should `smol::Timer` work inside a `tokio` runtime? about smol HOT 2 CLOSED

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().

from smol.

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?

from smol.