# Horrible Experience With Async Today

**URL:** <https://users.rust-lang.org/t/horrible-experience-with-async-today/122826>\
**Category:** uncategorized\
**Created:** [December 20, 2024, 10:07pm UTC](https://users.rust-lang.org/t/horrible-experience-with-async-today/122826 "2024-12-20T22:07:38Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\
**Post date:** [December 20, 2024, 10:49pm UTC](https://users.rust-lang.org/t/horrible-experience-with-async-today/122826/3 "2024-12-20T22:49:53Z")

</div>

One approach that's fairly straightforward is to wrap that upstream async client in a sync channel interface.

The basic idea is you have a request channel that you use something like [`blocking_send()`](https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.html#method.blocking_send) to send a pair of the request body and a one-shot response channel. You then block on the response channel for the reply.

The wrapped API then sits in a loop spawned from main that pulls requests off the other end, spawns the task to invoke them and send the response back on the one-shot.

Most of the thinking is about how much buffering you need and error handling, it's otherwise fairly simple to pull off.

Less efficient of course, but you're already making network calls here, it shouldn't tip the needle. And you can put anything you want in the request, of course, so you can batch up work or whatever.

---

_[View the full topic](https://users.rust-lang.org/t/horrible-experience-with-async-today/122826)._
