#[tokio::main]
async fn main() {
    tauri::async_runtime::set(tokio::runtime::Handle::current());
    // ...
5.1.1. Inside Tauri
If we make all of our async calls inside of Tauri, then Tauri can own and manage the Tokio runtime.
fn main() {
    // ...
    tauri::Builder::default()
        .setup(|app| {
            tokio::spawn(async move {
                async_process(
                    async_process_input_rx,
                    async_process_output_tx,
                ).await
            Ok(())
        // ...
This is the method we’re going to use because it is slightly simpler.

5.1.2. Outside Tauri
If we make any async calls outside of Tauri, then we need to own and manage the Tokio runtime.
#[tokio::main]
async fn main() {
    tauri::async_runtime::set(tokio::runtime::Handle::current());
    // ...
    tokio::spawn(async move {
        async_process(
            async_process_input_rx,
            async_process_output_tx,
        ).await
    tauri::Builder::default()
        // ...
5.2. Creating the Channels
The tokio::mpsc channels need to be created for both directions: inputs to the async process and outputs from the async process.
fn main() {
    // ...
    let (async_process_input_tx, async_process_input_rx) = mpsc::channel(1);
    let (async_process_output_tx, async_process_output_rx) = mpsc::channel(1);
    // ...
5.3. Running the Async Process
We’ll have Tauri own and manage the Tokio runtime so we’ll need to run the async process inside tauri::Builder::setup().
fn main() {
    // ...
    let (async_process_input_tx, async_process_input_rx) = mpsc::channel(1);
    let (async_process_output_tx, async_process_output_rx) = mpsc::channel(1);
    tauri::Builder::default()
        // ...
        .setup(|app| {
            tokio::spawn(async move {
                async_process(
                    async_process_input_rx,
                    async_process_output_tx,
                ).await
            Ok(())
        // ...
5.4. Main Thread to Async Process





    

Sending messages from the main thread to the async process requires more sophistication.
This additional sophistication is dictated by the need for our command to have mutable access to input channel for the async process.
To review, the main thread receives a message from JavaScript via a Tauri Command.
The Command then needs to forward the message to the async process via input channel for the async process.
The Command needs access to the channel.
So how do we get give the Command access to the input channel?
The answer is tauri::State<T>.
We can use Tauri’s state management system to pass the input channel to the Command.
The Tauri Command guide covers state management but it is missing a key piece.
Mutability.
We need mutable access to the input channel but Tauri managed state is immutable and what good is state if you can mutate it?
How do we get mutable access to the input channel via immutable state?
The answer is interior mutability and "the most basic type for interior mutability that supports concurrency is Mutex<T>"[1].
We can’t use std::sync::Mutex<T> because we need to .await a send() on the input channel and the guard for std::sync::Mutex<T> cannot be held across an .await.
However, the guard for tokio::sync::Mutex<T> can!
First, we create a struct that wraps a mutex on the input channel.
struct AsyncProcInputTx {
    inner: Mutex<mpsc::Sender<String>>,
This wrapper struct simplifies the type signature.
Instead of having to write Mutex<mpsc::Sender<String>> everywhere, we only have to write AsyncProcInputTx.
Then, we put our input channel into a mutex, put the mutex into our wrapper struct, and hand it off to Tauri to manage via tauri::Builder::manage.
fn main() {
    // ...
    tauri::Builder::default()
        .manage(AsyncProcInputTx {
            inner: Mutex::new(async_proc_input_tx),
        // ...
Finally, we can access this immutable state in our command, take a lock on the Mutex to get mutable access to the input channel, put the message in the channel, and implicitly unlock the Mutex when the guard goes out of scope at the end of the function.
#[tauri::command]
async fn js2rs(message: String, state: tauri::State<'_, AsyncProcInputTx>) -> Result<(), String> {
    info!(?message, "js2rs");
    let async_proc_input_tx = state.inner.lock().await;
    async_proc_input_tx
        .send(message)
        .await
        .map_err(|e| e.to_string())
5.5. Async Process to Main Thread

In comparison, sending messages from the async process to the main thread is trivial.
We spawn an async process that pulls messages out of the output channel and forwards them to our rs2js function.
fn main() {
    // ...
    tauri::Builder::default()
        // ...
        .setup(|app| {
            // ...
            let app_handle = app.handle();
            tauri::async_runtime::spawn(async move {
                loop {
                    if let Some(output) = async_proc_output_rx.recv().await {
                        rs2js(output, &app_handle);
            Ok(())
        // ...
6. Result
The following demo shows three messages "a", "b", and "c" sent from the webview to the async Rust process and back.
When the "Send to Rust" button is clicked, the frontend
reports the message in the "js2rs events" portion of the page,
and sends the message to the main thread.
The main thread
receives the message,
reports the message in the terminal,
and sends the message to the async process.
The async process,
receives the message
and sends the message back to the main thread.
The main thread,
receives the message,
reports the message in the terminal,
and sends the message to the frontend.
The frontend,
receives the message,
and reports the message in the "rs2js events" portion of th page.


Here is the complete Rust code in src-tauri/src/main.rs
#![cfg_attr(
    all(not(debug_assertions), target_os = "windows"),
    windows_subsystem = "windows"
use tauri::Manager;
use tokio::sync::mpsc;
use tokio::sync::Mutex;
use tracing::info;
use tracing_subscriber;
struct AsyncProcInputTx {
    inner: Mutex<mpsc::Sender<String>>,
fn main() {
    tracing_subscriber::fmt::init();
    let (async_proc_input_tx, async_proc_input_rx) = mpsc::channel(1);
    let (async_proc_output_tx, mut async_proc_output_rx) = mpsc::channel(1);
    tauri::Builder::default()
        .manage(AsyncProcInputTx {
            inner: Mutex::new(async_proc_input_tx),
        .invoke_handler(tauri::generate_handler![js2rs])
        .setup(|app| {
            tauri::async_runtime::spawn(async move {
                async_process_model(
                    async_proc_input_rx,
                    async_proc_output_tx,
                ).await
            let app_handle = app.handle();
            tauri::async_runtime::spawn(async move {
                loop {
                    if let Some(output) = async_proc_output_rx.recv().await {
                        rs2js(output, &app_handle);
            Ok(())
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
fn rs2js<R: tauri::Runtime>(message: String, manager: &impl Manager<R>) {
    info!(?message, "rs2js");
    manager
        .emit_all("rs2js", format!("rs: {}", message))
        .unwrap();
#[tauri::command]
async fn js2rs(
    message: String,
    state: tauri::State<'_, AsyncProcInputTx>,
) -> Result<(), String> {
    info!(?message, "js2rs");
    let async_proc_input_tx = state.inner.lock().await;
    async_proc_input_tx
        .send(message)
        .await
        .map_err(|e| e.to_string())
async fn async_process_model(
    mut input_rx: mpsc::Receiver<String>,
    output_tx: mpsc::Sender<String>,
) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    while let Some(input) = input_rx.recv().await {
        let output = input;
        output_tx.send(output).await?;
    Ok(())
}
From Rust-101, Part 15: Mutex, Interior Mutability (cont.), RwLock, Sync ↩