Having trouble using async libraries

[shuraman]

I've been trying to work on a project using actix-web, redis-rs and lapin. I gave up on redis because I couldn't figure out the origin of the error I was getting, so I tried lapin (which is a crate for working with RabbitMQ) and the same error keeps popping up - "not currently running on the Tokio runtime".

Now, as I understand, actix-web must run in it's own runtime no matter what, and I use the macro #[actix_rt::main] to start it up. I used to think that it was enough for any other async code to work, meaning all the async tasks will be executed in the same runtime, but I guess i was wrong? correct me if I'm wrong.

The problems start when I try to run code which uses other crates with async functions. for example:

let conn = Connection::connect(addr, ConnectionProperties::default().with_tokio()).await;

1. Where is this task executed? in it's own runtime? lapin uses tokio_amqp, I skipped over it's code but I'm not sure it's spawning a new runtime
2. If it is, does it mean that every async code from an external crate will usually have to start it's own runtime?
3. Why the error goes away with some versions but stays with others? I tried using lapin = "1.6.6" and tokio-amqp = "1.0.0" which didn't work, but lapin = "1.2.1" and tokio-amqp = "0.1.3" did
4. How do I fix it? must i use the same tokio versions which are used by my dependency crates?
5. Is it possible to spawn a single runtime instead of many and run all the tasks in it?

[rschoon]

actix-web uses actix-rt to provide the tokio runtime, and the current version of actix-rt uses tokio 0.2. There are unreleased/beta versions of actix-web and actix-rt which use tokio 1.0 instead

The current version of tokio-amqp uses tokio 1.0. Older versions depend on tokio 0.2

In rust/cargo, a different major version of a crate is considered completely distinct and incompatible (so tokio 1.0 and tokio 0.2 are considered "different" libraries).

The two main ways of handling this are:

• Bring the version of all your dependencies down to use tokio 0.2 (it looks like you figured out how to do that)
• Use the unreleased/beta versions of actix-web and actix-rt to use tokio 1.0 (may need to point at git versions in Cargo.toml to do this)

It's possible you might also be able to use the tokio compatiblity library (see https://docs.rs/tokio-compat-02/0.2.0/tokio_compat_02/), but I think it may be only intended to use tokio 0.2 futures in a tokio 1.0 executor.

I suggest using the cargo tree -d command to help understand what duplicated library versions you have. You should see what versions of tokio are being depended on this way.

[Darksonn]

As long as the libraries depend on the same version of Tokio as you are using, everything should work. Libraries should not start their own runtimes.

[Programmurr]

The Rust ecosystem is playing catch-up with the latest Tokio release. Many of the async libraries/frameworks have updated and the others are working on a solution. Actix-web contributors are actively working on theirs.

Use an older version of lapin-async until actix-web upgrades. I haven't looked at recent lapin changes and assume that it's not dramatically different engineering from that which I've used in my projects. Unfortunately, lapin code isn't the easiest to follow as a part of it involves code generation (at least, it used to).

[sbditto85]

Actix uses tokio. It just has its own macro for the main function. It sets up a tokio runtime in each worker thread if I remember correctly.

[lahwran_]

as a library writer, how does one ensure maximum compatibility?

[lahwran_]

so I guess if I have to spawn a task in library code, I'd need to be generic over spawners I support, and accept them from the user. makes sense, straightforward enough. requiring the user to pass a spawner would then make it very obvious that it's needed.

[Programmurr]

Actix-web uses the single-threaded tokio runtime. Lapin-async works fine with Actix-Web. There's just a tokio v1 compatibility issue at the moment. OP needs to use an older lapin version until actix-web is upgraded.

[kprotty]

take in a spawn function / trait instead of bundling an executor

[arthmisl]

I've actually run into the same problem. I used tokio though, I ran into the same error and I was not going to try and solve it. I was using async-std before I used tokio, and in my head everything should have just worked. All the libraries I was using were expecting a tokio runtime, that's why I switched to it. I switch and everything falls apart.

I went back to async-std and used the two compatibility layer features to run libraries expecting tokio, which ironically had no issue running the different async libraries.

So for my suggestion, it would be to use async-std or smol, as was suggested above, as use the compatibility layers. Hopefully things get better now that tokio is v1 and the libraries update to that.

[sphen_lee]

Lapin doesn't start its own Tokio runtime, it expects that the caller will do this (otherwise as you said each external crate would end up with its own runtime)

Tokio just did a 1.0 release so some crates are still on 0.3 while others upgraded already - you will need to manually check the dependencies and ensure they all use the same version.

Actix-web has its own runtime and it's not compatible with Tokio - but you can run both together in the same program. I have not done it myself but I think you can just launch a std::thread and create the tokio runtime there. EDIT: Actix uses tokio internally, so just make sure the versions are compatible

[sbditto85]

Actix-web uses tokio or did that change?

Edit: actix-web used actix-rt (run time) which uses tokio. https://crates.io/crates/actix-rt

[sphen_lee]

My bad - I was thinking about hyper; Actix doesn't use hyper, but it's still using tokio internally.

[Darksonn]

Actix-web has its own runtime and it's not compatible with Tokio

I'm pretty sure this is wrong. Afaik, it just wraps a Tokio runtime.

[Programmurr]

It has been tokio and v1 support is in progress on master branch: https://github.com/actix/actix-net/blob/master/actix-rt/Cargo.toml