So, while we’ve seen with our own eyes that the executor and reactor could be loosely coupled, which in turn means that you could in theory mix and match reactors and executors, the question is why do we encounter so much friction when trying to do just that?

Most programmers that have used async Rust have experienced problems caused by incompatible async libraries, and we saw an example of the kind of error message you would get previously.

To understand this, we have to dive a little bit deeper into the existing async runtimes in Rust, specifically those we typically use for desktop and server applications.

Explicit versus implicit reactor instantiation

Info

The type of future we’ll talk about going forward is leaf futures, the kind that actually represents an I/O operation (for example, HttpGetFuture).

When you create a runtime in Rust, you also need to create non-blocking primitives of the Rust standard library. Mutexes, channels, timers, TcpStreams, and so on are all things that need an async equivalent.

Most of these can be implemented as different kinds of reactors, but the question that then comes up is: how is that reactor started?

In both our own runtime and in Tokio, the reactor is started as part of the runtime initialization. We have a runtime::init() function that calls reactor::start(), and Tokio has a Runtime::new() and Runtime::enter() function.

If we try to create a leaf future (the only one we created ourselves is HttpGetFuture) without the reactor started, both our runtime and Tokio will panic. The reactor has to be instantiated explicitly.

Isahc, on the other hand, brings its own kind of reactor. Isahc is built on libcurl, a highly portable C library for multiprotocol file transfer. The thing that’s relevant for us, however, is that libcurl accepts a callback that is called when an operation is ready. So, Isahc passes the waker it receives to this callback and makes sure that Waker::wake is called when the callback is executed. This is a bit oversimplified, but it’s essentially what happens.

In practice, that means that Isahc brings its own reactor since it comes with the machinery to store wakers and call wake on them when an operation is ready. The reactor is started implicitly.

Incidentally, this is also one of the major differences between async_std and Tokio. Tokio requires explicit instantiation, and async_std relies on implicit instantiation.

I’m not going into so much detail on this just for fun; while this seems like a minor difference, it has a rather big impact on how intuitive asynchronous programming in Rust is.

This problem mostly arises when you start programming using a different runtime than Tokio and then have to use a library that internally relies on a Tokio reactor being present.

Since you can’t have two Tokio instances running on the same thread, the library can’t implicitly start a Tokio reactor. Instead, what often happens is that you try to use that library and get an error like we did in the preceding example.

Now, you have to solve this by starting a Tokio reactor yourself, use some kind of compatibility wrapper created by someone else, or seeing whether the runtime you use has a built-in mechanism for running futures that rely on a Tokio reactor being present.

For most people who don’t know about reactors, executors, and different kinds of leaf futures, this can be quite unintuitive and cause quite a bit of frustration.

Note

The problem we describe here is quite common, and it’s not helped by the fact that async libraries rarely explain this well or even try to be explicit about what kind of runtime they use. Some libraries might only mention that they’re built on top of Tokio somewhere in the README file, and some might simply state that they’re built on top of Hyper, for example, assuming that you know that Hyper is built on top of Tokio (at least by default).

But now, you know that you should check this to avoid any surprises, and if you encounter this issue, you know exactly what the problem is.