3 ms·
>now you're having to fire up a tokio runtime I've been developing in (mostly async) Rust professionally for a about a year -- I haven't written much sync rust
by collinvandyck76 2y ago
>now you're having to fire up a tokio runtime
I've been developing in (mostly async) Rust professionally for a about a year -- I haven't written much sync rust other than my learning projects and a raytracer I'm working on, but what are the kind of common dependencies that pose this problem? Like wanting to use reqwest or things like that?
- Animats 2y ago> Like wanting to use reqwest or things like that? Yes. Reqwest cranks up Tokio. The amount of stuff it does for a single web request is rather large. It cranks up a thread pool, does the request, and if there's nothing else going on, shuts down the thread pool after a while. That whole reqwest/hyper/tokio stack is intended to "scale", and it's massive overkill for something that's not making large numbers of requests. There's "ureq", if you don't want Tokio client side. Does blocking HTTP/HTTPS requests. Will set up a reusable connection pool if you want one.
- zozbot234 2y agoYou don't have to do that, Tokio also provides a single-threaded runtime that just runs async tasks on the main thread.
- chromatin 2y agoreqwest also has a blocking version, which I use in projects not already using an async rt https://docs.rs/reqwest/latest/reqwest/blocking/index.html https://docs.rs/reqwest/latest/reqwest/blocking/index.html
- cmrdporcupine 2y agoThe blocking implementation still depends on and uses tokio, last I looked. I've seen this with multiple Rust packages. "Yes, we offer a synchronous blocking version..." and then you look and it's calling rt.block_on behind the scenes. Which is a pretty large facepalm IMHO