Usage with async-std?

[WhyNotHugo]

I'm working on a codebase which uses a lot of async-std.

I now need to make a few http requests, and reqwests seems to be the ubiquitous recommendation for my use case. However, trying to use it immediately panicks:

thread 'webcal::test::test_dummy' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', /home/hugo/.local/state/cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.23/src/client/connect/dns.rs:121:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The message is pretty clear: I must be using tokio to use reqwests. However, I can't use tokio because that would require re-writing everything I already have using async-std (and a lot of the functionality isn't even available in tokio). As far as I understand, futures and other under-the-hook types are the same.

Is it somehow possible to use reqwest with async-std? What's the hard-requirement that currently restricts reqwests to only work with the tokio runtime?

[seanmonstar]

a lot of the functionality isn't even available in tokio

This is the first I've heard this. Tokio is significantly more common, and so I'd expect the opposite to be the case.

What's the hard-requirement that currently restricts reqwests to only work with the tokio runtime

reqwest is opinionated, and chooses to work specifically with Tokio (and WASM as an alternative).

[WhyNotHugo]

reqwest is opinionated, and chooses to work specifically with Tokio (and WASM as an alternative).

I'm very curious to understand, why does a library have to be tied to a specific runtime? No trying to argue here, but just understand the technical situation a bit better.

Both rely on standard rust features like await and async, and use common/shared types like future and such.

I had the (apparently wrong) impression that async code could be agnostic to which runtime is running under the hood, and I'm trying to understand why that's wrong.

[WhyNotHugo]

Oh, this is fully explained here:

The default Client uses an HttpConnector which makes use of tokio::net::TcpStreams. You can disable the relevant features and bring your own runtime.

[WhyNotHugo]

This is the first I've heard this. Tokio is significantly more common, and so I'd expect the opposite to be the case.

You're actually right, it does seem to support everything I need. And its API matches the std one too. I think my familiarity with this has aged poorly; I'll give tokio::fs a try.

[WhyNotHugo]

Scrub that; tokio returns types that do blocking IO under the hood:

pub fn path(&self) -> PathBuf

On network mounts (with higher latency) this blocking IO freezes a service.

[seanmonstar]

What piece are you referring to? That function isn't doing any IO, from what I can tell: https://github.com/rust-lang/rust/blob/96ddd32c4bfb1d78f0cd03eb068b1710a8cebeef/library/std/src/sys/unix/fs.rs#L718

[WhyNotHugo]

PathBuf itself does blocking IO. I've reported that upstream tho, it's not in scope here: tokio-rs/tokio#5192

I've found workarounds, but, usually, the API is very delicate because it's very easy to end up doing blocking IO (e.g.: .path().exists() will do blocking IO.