Signal panicking when being set in a separate thread about freya HOT 8 OPEN

Spawning the async task with tokio is probabl causing this, just move the task out of it

spawn(async move {
  while let Ok(event) = terminal_event_rx.recv() {
          match event {
              TerminalEvent::Redraw {
                  lines,
                  cursor,
                  scroll_top,
              } => {
                  *rendered_lines.write() = lines;
                  *rendered_cursor.write() = (cursor.x, cursor.y as usize);
                  *rendered_scroll_top.write() = scroll_top;
              }
          }
      }
  });

from freya.

Moving it outside the tokio task will actually block the main thread & the app freezes. I tried using std::thread::spawn instead of dioxus spawn but the error still persist.

from freya.

Can't you just use a non-blocking, async-friendly channel instead of crossbeam ? Like https://docs.rs/tokio/latest/tokio/sync/mpsc/fn.unbounded_channel.html

from freya.

I've just switched to flume to have async recv channel:
https://github.com/ZeroX-DG/raven/blob/db0b86052b4fbc101562990d9678c19df2482dd0/src/components/content_area.rs#L63

But now I run into the old bug in #602. Maybe something is blocking the thread again 😢 I'll investigate more.

from freya.

Can you try with tokio just in case?

from freya.

Btw I wonder if for the terminal renderer it would be better to use the canvas directly, that would surely be more performant

from freya.

Yep. Same thing happen using tokio channel.

thread 'main' panicked at /Users/viethung/.cargo/git/checkouts/freya-aa88117f1f713ee2/7b68806/crates/core/src/dom/mutations_writer.rs:46:60:
called `Option::unwrap()` on a `None` value

Here's my branch for the tokio channel if you want to check it out:
https://github.com/ZeroX-DG/raven/tree/tokio-channel

from freya.

But yeah. Implementing in cavas would indeed be more performant & avoid blocking UI thread problem. I'll try that instead!

from freya.