4 ms·
I'm hopeful that this leads to some focus on the ergonomics of "waiting for async things from sync code". Lots of "handlers" in the universe have synchronous in
by boulos 6y ago
I'm hopeful that this leads to some focus on the ergonomics of "waiting for async things from sync code". Lots of "handlers" in the universe have synchronous interfaces, so if you want to implement them you end up needing to poll/wait on async from a regular function. I swear that every time I poke at Rust, I seem to find some way to cut my fingers...
My specific example is writing a fuse handler (now with cberner/fuser formerly zargony/rust-fuse) for GCS/S3. If you want to use make any async requests (like via hyper), you currently have to roll your own poller, like reqwest does in blocking mode [1].
The rust async/.await primer [2] offers the reader the seemingly helpful futures::executor::block_on, but basically no two executors can interact (and for good reason!). As others highlight, the ecosystem seems like it's going to end up standardizing on tokio (and/or some flavor thereof) and that hopefully now that it's 1.0, we can have stable enough deps for a while :).
[1] https://github.com/seanmonstar/reqwest/blob/5ee4fe5ab64a2e3d81efb9540cb9bdb98b8d6938/src/blocking/wait.rs#L10 https://github.com/seanmonstar/reqwest/blob/5ee4fe5ab64a2e3d...
[2] https://rust-lang.github.io/async-book/01_getting_started/04_async_await_primer.html https://rust-lang.github.io/async-book/01_getting_started/04...
- vlmutolo 6y agoI've encountered the "wait on async things from sync code" issue several times, too. I have found that something like `block_on` from either `futures` or `futures_lite` often does the trick. https://docs.rs/futures-lite/1.11.3/futures_lite/future/fn.block_on.html https://docs.rs/futures-lite/1.11.3/futures_lite/future/fn.b...
- boulos 6y agoRight, but depending on the tokio version (maybe) using block_on results in a hang or panic. I’ll see if futures_lite is any different, but I think it’s mostly on tokio’s side.
- masklinn 6y ago> depending on the tokio version (maybe) using block_on results in a hang or panic Isn't it mostly a function of what runtime you're using? `block_on` with a single-threaded runtime can't run tasks elsewhere (since there's only one thread which you're blocking) so depending on the version it would either hang (before detection of that situation was added) or panic, with an error message saying to use a multithreaded runtime. I completely agree that it's a pain in the ass though, especially since there are situations where tokio must be coerced into using anything but the basic scheduler (e.g. tests).
- aliceryhl 6y agoTokio has a version of block_on too that you can use with those libraries.