Dioxus 0.7.10 UI Freezes (Not the Tokio Runtime)

[dmorigin]

Using:

• OS: Windows
• Dioxus: 0.7.10 (desktop only | No Fullstack)
• Rust: 1.97.1 (stable)

TOML:

• dioxus = { version = "0.7", features = ["router"] }
• tokio = { version = "*", features = ["sync", "rt-multi-thread", "rt", "time", "macros", "io-util"]}

Description:
I'm playing around with Dioxus, the first time and want to test out something. But now, the UI freezes and the CPU spins up to 13%-15% only for the application thread. Not the WebView (Threads).

Dioxus runs inside my own Tokio Runtime (6 Worker Threads)

        let rt = tokio::runtime::Builder::new_multi_thread()
            .name("dioxus")
            .enable_all()
            .worker_threads(globals::TOKIO_WORKER)
            .thread_name_fn(|| {
                use std::sync::atomic::{AtomicUsize, Ordering};

                static ATOMIC_ID: AtomicUsize = AtomicUsize::new(0);
                let id = ATOMIC_ID.fetch_add(1, Ordering::SeqCst);
                format!("dioxus-worker-{}", id)
            })
            .build()?;

        // Startet den Dioxus Desktop Client
        let result: Result<(), ApplicationError> = rt.block_on(async move {
            process_main_desktop_thread().await?;
            Ok(())
        });

Previously I startet a worker Thread with [tokio::spawn], which is doing some stuff. Including to scan a folder we a lot of files inside. Therefore, this scan task is spawned with [tokio::task::spawn_blocking] to avoid UI freezing. The communication between this service task and the Dioxus Task is handled by [tokio::sync::mpsc::channel()]. My service task processes incoming commands during [tokio::sync::Receiver::recv()] and sends messages by calling [tokio::sync::Sender::send()]. Nothing special.

Now the Dioxus Task site: I need to wait for incoming message from my service task. Like this:

pub fn use_incoming_messages() -> ReadSignal<Vec<Message>> {
    let mut signal = use_signal(Vec::<Message>::new);

    use_future(move || async move {
        log_debug!("[use_future]: Create new listener");
        match use_service_task().listen() {
            Ok(mut listener) => {
                let mut buffer = Vec::<Message>::with_capacity(20);

                while !listener.is_closed() {
                    tokio::time::sleep(Duration::from_millis(500)).await;
                    let received = listener.recv_many(&mut buffer, 20).await;
                    log_debug!("[use_music_library_message]: Tick => received {} messages", received);
                    if received > 0 {
                        signal.set(buffer.clone());
                        buffer.clear();
                    }
                }

                log_warning!("[use_future]: Listener closed");
            },
            Err(err) => log_error!(err)
        }
    });

    signal.into()
}

This is the "batch" version. I tried this to avoid message flooding at the Dioxus task. Inside a component, it looks like this:

#[component]
fn MyComponent() -> Element {
    let library = use_service_task();
    let library_message = use_incoming_messages();
    let mut library_scan_running = use_signal(|| false);

    use_effect(move || {
        for message in library_message.read().iter() {
            match message {
                Message::LibraryScanStarted => library_scan_running.set(true),
                Message::LibraryScanFailed(_) => library_scan_running.set(false),
                Message::LibraryScanFinished => library_scan_running.set(false),
                _ => {}
            }
        }
    });

   rsx! { ... }
}

This is an example.

Now, if I start my appllication, it works, as expected. I'm able to send a message to my service task and I can receive a message from the service task. But, at that moment I start a library scan, the workload becomes more heavy with more incoming messages on the Dioxus site. This forces Dioxus to freez at some point. Sometimes a scan can be finished, without any errors, sometimes not. I the scan task is completed and starting a second run, the UI freezes. I also tried to use [use_signal_sync] instead of [use_signal].

My service task runs in the background. This task does not freeze. It's only the UI.

Any ideas?

[RenSolvyn]

I rebuilt your exact pattern headlessly against the dioxus v0.7.10 source (VirtualDom driven the way dioxus's own core tests drive it: rebuild, wait_for_work, render_immediate, no display needed) and put it under a message flood. Three results, and together they point very precisely at where your freeze lives.

First, the good news: the code you posted is innocent. The future-with-recv_many loop, the signal.set of the buffer, and the effect that reads messages and writes scan_running ran fully bounded under a flood of tens of thousands of messages: 492 batch ticks produced exactly 493 renders and 493 effect runs over 3 seconds, a clean 1:1:1 with no growth. Your custom multi-thread tokio runtime is also fine: packages/desktop/src/launch.rs (lines 109-123 in v0.7.10) explicitly detects an ambient runtime via Handle::try_current() and adopts it, only rejecting the current-thread flavor. Yours is multi-thread, so that whole area is supported and not your bug.

Now the mechanism that does produce your exact symptom. In v0.7.10, use_effect subscribes to every signal it reads during its run (packages/hooks/src/use_effect.rs: the callback runs inside a ReactiveContext, and any tracked read means a later write to that signal re-queues the effect). There is deduplication within one queue cycle, but no guard across cycles. So an effect that reads a signal it also writes re-queues itself forever, and the spin is synchronous inside the scheduler's work loop: measured headlessly, that control case ran the effect 4,360,690 times while renders stayed frozen at 1 and the driver's own timeout could not even fire. On desktop that is the main thread never returning to the event loop: frozen window, no error, one core pinned at a fixed percentage. That is your 13-15 percent.

The critical part: you wrote "This is an example" about your effect body, and one entirely natural line turns your innocent example into the freeze. I mutated the verified-clean version by adding only a guard read:

Message::LibraryScanStarted => {
    if !*scan_running.read() {   // this read subscribes the effect to scan_running
        scan_running.set(true);
    }
}

That single change livelocked the identical harness: about 24,000 render-churn cycles, the recv future starved at 64 ticks, then the terminal spin. The guard reads scan_running, the set writes it, the effect is now subscribed to its own output, and any batch containing both a start and a stop message toggles it forever. This also matches your "sometimes a scan finishes, sometimes not" and "second run freezes" pattern, since it only triggers when one effect pass observes both state transitions.

So the audit for your real code: in every use_effect, look for any signal that is both read and written in the same body, counting reads hiding inside conditions, logging, or helper calls. The fixes, in order of preference:

1. If the effect must consult a signal it writes, read it untracked: scan_running.peek() instead of scan_running.read() (peek exists on signals in 0.7 exactly for this).
2. Better, derive state instead of imperatively syncing it: let scan_running = use_memo(move || messages.read().iter().rev().find_map(|m| match m { ... })) removes the effect entirely.
3. If neither fits, split the effect so the branch that writes a signal never reads it.

If the audit finds nothing, the discriminating next step is binary search: comment out effect bodies one at a time under load; the freeze will vanish with a specific one, and the read-write pair will be inside it. Happy to share the headless harness (about 150 lines, no GUI required) if you want to reproduce any of this or test your real effect bodies directly.

One caveat for honesty: I ran this on Linux against the shared core scheduler, not on Windows with the WebView attached. But the livelock measured here never yields the driving thread at all, which is renderer-independent, and it reproduces your symptom signature exactly.

[dmorigin]

Thank you for your answer. So I started to comment out alot of code. At the End I removed any custom hook which contains a listener. Except one single.

///
///
#[derive(Debug, Clone)]
pub struct SettingsContext {
    client: SettingsClient,
    message: MessageHandlerClient
}

///
///
pub fn use_settings() -> SettingsContext {
    use_context::<SettingsContext>()
}

///
///
pub fn use_settings_message() -> ReadSignal<SettingsMessage> {
    let mut signal = use_signal(|| SettingsMessage::Empty);

    // receive settings messages
    use_future(move || async move {
        log_debug!("[use_future]: Process incoming messages");

        match use_settings().listen() {
            Ok(mut listener) => {
                while let Some(message) = listener.recv().await {
                    log_debug!("Received settings message: {}", message);
                    signal.set(message);
                }
            },
            Err(err) => log_error!(err)
        };
    });

    signal.into()
}

This code is only executed if I click a button. At that moment a Message is send to my Settings Server. It handles the change of a single setting and broadcast the change to any subscriber. To filter out a single setting, you could proceed as follows

//    let message = use_settings_message();
//    use_memo(move || {
//        log_debug!("[use_memo]: Check incoming message is of key '{}'", key);
//
//        match message.read().cloned() {
//            SettingsMessage::SettingChanged(name, value) if name == key => {
//                if let Ok(value) = value.try_into::<V>() {
//                    log_debug!("Setting of key '{}' changed", key);
//                    value
//                } else {
//                    default_value.clone()
//                }
//            },
//            _ => default_value.clone()
//        }
//    })

This code is part of another custom hook. This hook uses the use_settings_message() hook above. I tried it with a memo (general works) as well as with a use_effect (also works).

//    use_effect(move || {
//        match message.read().cloned() {
//            SettingsMessage::SettingChanged(name, value) if name == key => {
//                if let Ok(value) = value.try_into::<V>() {
//                    log_debug!("Setting of key '{}' changed", key);
//                    signal.set(value);
//                }
//            },
//            _ => {}
//        }
//    });

I think, there is no issue with both version of filtering. Both are commented out. To eliminate the possibility that there is an issue here. The UI is still freezing. At any point there is no Signal::read(). It is, that at this moment I use the use_future hook (from above) the UI starts freezing after a while. Once I’ve changed my settings enough. At that moment, I comment out the function body (no call of use_future() anymore), I can change my settings as often as I want.

Ok... back to my use_settings_message() hook. The last custom hook with a body. I tried the following

pub fn use_settings_message() -> ReadSignal<SettingsMessage> {
    let mut signal = use_signal(|| SettingsMessage::Empty);

    // receive settings messages
    use_future(move || async move {
        log_debug!("[use_future]: Process incoming messages");

        match use_settings().listen() {
            Ok(mut listener) => {
                while let Some(message) = listener.recv().await {     <=== The broken part?
                 // <=== We don't set any Signal anymore  ===>
                //    log_debug!("Received settings message: {}", message);
                //    signal.set(message);
                }
            },
            Err(err) => log_error!(err)
        };
    });

    signal.into()
}

And yes... at that moment I comment out the loop [while let Some(message) = listener.recv().await { ... }]. It works... My loop has any working body any more. So it's doing nothing. Except receiving a message from the tokio::sync::mpsc channel. Has Tokio a bug? With an empty loop, the UI freezes after around 100 to 150 received messages (change of an setting). Without that loop... I can change my setting over 600 times without any issue.

[dmorigin]

Ok, I did a simple test

    #[test]
    fn test_mpsc_channel() {

        let rt = tokio::runtime::Builder::new_multi_thread()
            .name("dioxus")
            .enable_all()
            .worker_threads(globals::TOKIO_WORKER)
            .build().unwrap();

        rt.block_on(async move {
            let (tx, mut rx) = tokio::sync::mpsc::channel(globals::TOKIO_CHANNEL_SIZE);

            tokio::spawn(async move {
                while let Some(message) = rx.recv().await {
                    match message {
                        SettingsMessage::SettingChanged(key, value) => {
                            println!("Received: {} = {:?}", key, value);
                        },
                        _ => {}
                    }
                }
            });

            let mut value = String::from("light");
            let mut toggle: bool = true;

            for count in 0..1000 {
                println!("Send Message Index: {}", count);
                tx.send(SettingsMessage::SettingChanged(String::from("app.theme"), toml::Value::from(value))).await.unwrap();
                //tokio::time::sleep(Duration::from_millis(100)).await;

                if toggle { value = String::from("dark"); }
                else { value = String::from("light"); }

                toggle = !toggle;
            }
        });
    }

Works as intended. But I have a quest. What happend to the [tokio::sync::mpsc::Receiver::recv()] if [tokio::sync::mpsc::Sender] hangs or sit on the message queue? Sometimes I use [tokio::sync::mpsc::Sender::try_send()] instead.

[RenSolvyn]

This is excellent debugging, and I want to update honestly first: your data falsifies my first mechanism as the cause of YOUR freeze. The read-write effect livelock I measured is real, but you removed every consumer, every signal.set, every tracked read, and it still froze; so it is not this. What your three experiments select instead is more interesting, and your own pure-tokio test is one of the pieces of evidence.

First your direct question, because it is load-bearing: recv().await cannot hang because a sender is stuck; it parks until a message arrives or every Sender is dropped, nothing else. The hang risk in bounded mpsc lives entirely on the send side: send().await on a full channel parks the SENDER until space frees. And a parked send is contagious: whatever task awaits it stops doing everything else. If that task is your settings server's broadcast loop, one full subscriber silently freezes delivery to all subscribers. try_send is the non-parking variant (TrySendError::Full immediately), and your instinct to reach for it is pointing at exactly the right layer.

Now look at the asymmetry you found, because it explains itself once you see the channel-close semantics. Without the recv loop, your future completes immediately, the Receiver is dropped, the channel is CLOSED, and every later send().await from the server fails instantly and moves on; nothing can ever fill; 600 changes work. With the empty loop, the receiver is alive; if at any point the dioxus task that polls it stops being polled, the bounded channel silently fills to capacity, the server's send().await parks, the server stops processing commands, your command channel backs up behind it, and the first send that runs on (or is awaited by) the UI thread freezes the window. No error anywhere, because every component is "just waiting".

You are almost certainly not alone in this, and that is the strongest evidence of all: there is an open dioxus issue, #5679, titled "[desktop] UI freezes in an existing Tokio runtime after cooperative budget exhaustion." That is your exact configuration (desktop, your own multi-thread runtime) and your exact symptom. Read it before you do anything else; if it matches, your case is a data point on a known bug, not a mistake in your code. The related merged PR #5430, "add wakeup callback for external event loop integration," is the shape of the real fix: it is about making the desktop event loop and the async runtime wake each other correctly, which is precisely the seam your freeze lives on.

That reframes the mechanism from "your channel" to "does the desktop scheduler keep polling your recv future." I tested the consequence of it not doing so, at the tokio layer, with a manual executor whose waker delivery I deliberately break after N wakes (modeling the scheduler ceasing to re-poll). The result: the bounded-channel drain halts, and how much it drains before halting scales linearly with both the number of wakes delivered and the channel capacity (measured: drain point moved from ~500 to ~1500 as I varied those). The instant the drain halts, the sender's send().await parks, exactly as the model requires; and when the receiver is instead dropped, every send fails fast, which is your no-loop case. So the cascade is real and measured; what I could not measure here is the first link, whether the dioxus desktop scheduler is the thing that stops polling, because that needs the GUI. #5679 is where that link is being tracked.

Three questions make your next post decisive:

1. Does [desktop] UI freezes in an existing Tokio runtime after cooperative budget exhaustion #5679 match your setup? If yes, add your reproduction there; it strengthens the bug report and you inherit its eventual fix.
2. What is globals::TOKIO_CHANNEL_SIZE, and does the freeze threshold move if you multiply it by 10? The model predicts the freeze point scales with channel capacity; that is a five-minute test that confirms or kills it on your machine. (It will not fix anything, since a bigger buffer only delays the fill, but it pinpoints the cause.)
3. In the frozen state, attach a debugger and look at the threads: the model predicts at least one parked inside tokio::sync::mpsc::Sender::send. That single stack frame is the whole diagnosis.

The clean control matters too, so you do not chase tokio itself: with a correctly delivering waker (the executor services every wake), the same foreign-executor recv loop drained 100000 of 100000 messages at capacities 8, 32, 128, and 512, no stall. So the answer to "has tokio a bug?" is a measured no: the primitive is fine when it is polled. The freeze appears only when wake delivery to the recv future stops, which is a scheduler-integration property, not a channel property, and is what #5679 and PR #5430 are about.

Fixes, in the order I would take them:

1. Settings are last-value state, and there is a tokio primitive with exactly those semantics: tokio::sync::watch. The server does watch::Sender::send(new_settings) which NEVER parks regardless of subscribers, and each UI subscriber does rx.changed().await then reads the latest. Slow or stalled subscribers simply skip intermediate values, which for settings is correct behavior. This deletes the entire deadlock class rather than tuning around it.
2. If you need event-stream semantics elsewhere, bridge the runtimes: tokio::spawn a small drain task per subscription that forwards from the tokio mpsc into an unbounded channel (futures::channel::mpsc::unbounded), and let use_future read the unbounded side. The side that can park now lives on a real tokio worker that UI scheduling can never starve, and the UI-facing side has no backpressure to deadlock on.
3. Regardless of the above, harden the server: never send().await to subscribers in the broadcast loop; use try_send with a drop-or-disconnect policy for full channels, so one bad subscriber can never freeze delivery to the rest.

Honest scope note: I could not compile dioxus 0.7 in today's environment (toolchain too old here), so the "task stops being polled" step is inference from your measurements rather than something I reproduced at the dioxus layer; the tokio layer is measured as clean. Your answers to the three questions above, especially the thread dump, will confirm or kill the model in one post.

[dmorigin]

One answer:
[pub const TOKIO_CHANNEL_SIZE: usize = 10000;]
I will play with this value. But later... it's 00:37 in the morning :D

Oh wow.... #5679, this could be the answer. It needs further testings. But my application runs with many library scans now. Without any issues. I let it run for a while, to make sure this was the solution. At the moment my application runs for around 1300s with a library scan every 20s.

What have I changed?
I wrapped the App Execution with

tokio::task::unconstrained(async move {
    dioxus::LaunchBuilder::new()
    ....
    .launch(|| app::App());
}).await;

Edit

This could also the explanation why [tokio::time::Interval] was doing strange things. With a [std::time::Duration] of 500ms, the ticks comes every 50ms and after a while Interval switches up to every 500ms. It also happens that first: every tick comes 500ms and then instant. An absolutely strange behavior. Therefore I switched in my custom hook use_incoming_messages() ( from my first posting ) to [tokio::time:sleep()].