When you wish to send a sequence of things across threads (in a thread-blocking way), you have e.g. crossbeam_channel.
When you wish to send a sequence of things across futures (in a non-thread-blocking, future-blocking way), you have e.g. tokio::sync::mpsc.
What would be something that enables me to send from a blocking thread, and receive from an asynchronous context ? (Btw, I could imagine needing the opposite at some point.)
I need the channel to be bounded, thread-blocking when sending and future-blocking when receiving.
I am looking for something somewhat performant, like an equivalent of what is done in crossbeam_channel, but waking up the future instead of the thread, with the ability to buffer some messages to avoid blocking as much as possible. The answer given here for the multiple messages scenario looks a bit like a patch-up to that regard.
The channels provided by Tokio have gained the feature to do this since this question was asked. You can simply call the blocking_send and blocking_recv methods on the channel when you are in non-async code:
let (mut tx, mut rx) = tokio::sync::mpsc::channel(10);
std::thread::spawn(move || {
// send a value, blocking synchronously
// this allows async channels to be used in non-async contexts
tx.blocking_send("testing").unwrap();
});
// receive a value, blocking asynchronously
assert_eq!(rx.recv().await.unwrap(), "testing");
Futures can be run synchronously in a blocking fashion. You can use futures::exector::block_on to do this, to allow sending in a non-async context:
let (mut tx, mut rx) = tokio::sync::mpsc::channel(10);
// send a value, blocking synchronously
// this allows async channels to be used in non-async contexts
futures::executor::block_on(tx.send("testing")).unwrap();
// receive a value, blocking asynchronously
assert_eq!(rx.recv().await.unwrap(), "testing");
With this snippet, running the future to send a value will block the thread until the future completes, similar to how the standard library channels work. This can also be used on the receiving side if desired.
crossfire seems to be a crate meant for exacly this.
ATM it’s pretty recent and not widely used though.
If you need multi-consumer, async-channel seems to be the standard.
It has dedicated functions for blocking interaction in addition to the async ones.