Rust. Best way to share state for many threads

[DaMilyutin]

Hello,
I'm trying to reimplement my C++ example for async counter with some jobs imitation and latency in Rust.
(C++: https://github.com/DaMilyutin/sixtyfps-cpp-template-worker-threads)

And I got into some difficulties here.
First to know, I'm new to Rust. I've read and watched some stuff but never practiced.
So I'm probably may ask some noob questions here.

What I have found now is that I must attach Rc wrapped VecModel to ui

    let mut task_data_model = Rc::new(sixtyfps::VecModel::<ListItemData>::default());
    //let task_data_model_handle = Arc::downgrade(&task_data_model);
    ui.set_task_data_model(sixtyfps::ModelHandle::new(task_data_model));
    
    for 
    
    export struct ListItemData := {
        id: int,
        progress: float,
    }
    
    property<[ListItemData]> task-data-model; 

But I can not change it in other spawned threads. I get error messages like
" sixtyfps::invoke_from_event_loop(|| {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Rc<VecModel<ListItemData>> cannot be shared between threads safely
"
I'm not sure what I'm doing wrong. There are so many strange to me wrappers in Rust:
Rc, Arc, ... etc 😄

When I change Rc to Arc I get type mismatch for argument for ui.set_task_data_model. I'm so confused.

Since I'm trying to make something similar to my C++ code, I probably think in wrong paradigm.
Please, advise any tools, paradigms or approaches to acomplish this async example,

See my code and error messages in zip:
counter-with-jobs.zip

Thank you for any help.
And Merry X-mas.
(We have orthodox X-mas in Jan7)

[ogoffart]

The model itself is not thread safe and cannot be sent to another thread.
We are still in need to find a better way to handle that. But for now, the solution with as_any of thread_local. See the first part of my comment there #747 (comment)

(Edit: link fixed)

[DaMilyutin]

@ogoffart I can not get about #47. It opens issue with ios support. There is no text.

What seems ok for me (with my newbie Rust understanding) is creating channel to pass message via enum into Async VecModel.
There are probably mesages like insert, remove, set.
I don't know if it is good idea. But I even could try to do this trick somehow with VecModel.

I wonder how did this all work with C++ but not with Rust?

[ogoffart]

Sorry, i pasted the wrong link. This is the right link: #747 (comment)

[quendimax]

Hello @ogoffart

I encountered the same problem some days ago. I looked at the actual issues, and didn't find related ones. Is there any updates/plans for adding thread safe version of slint structs/components?
For my case, a handy solution would be to declare thread safety structs in slint code using an attribute (a la @rust(async/thread-safe/or something like this) that could replace the internal ModelRc, VecModel and other thread unsafe types with the safe analogues (ModelArc, ...?).

For now I use unsafe Send/Sync like a workaround. But it would be fine to see a rusty safe solution for that.

Thank you.

[Vollbrecht]

Disclaimer: I am also new to rust.
I tinkered with your code and i kinda got it working. Unfortunately all the list elements spawn over each other so not perfect... My solution has some caveats but if you only want something working than it maybe shows a path in the right direction.
The first thing i tried was to create an global mutexd task_data_model. I failed to get it working because later i realized that for me the limitation was that the [ListItemData] property is an normal array -> array length need to be set at compile time. To overcome the issue i created just a bunch of empty ListItemData in the .60 file. If there is a better method i would also be interested to get dynamic connection here.
If you want to access the ui context now in a thread u need to to all the data manipulation inside the sixtyfps::infove_from_event_loop within the thread.
example ->

ui.on_request_increase_value( move || {
    //some work
    let ui_thread = ui_handle.clone();
    thread::spawn(move || {
        // run business logic 
        let ui = ui_thread.clone();
        sixtyfps::invoke_from_event_loop( move || {
                  let ui = ui.unwrap();
                  let data = ui.get_task_data_model();
                  data.set_row_data(
                        r,
                        ListItemData {
                            id: id,
                            progress: i as f32
                        },
                    );
          });
          thread::sleep(time::Duration::from_secs(1));
     });
});  
              

Because we got elements in our ListItemData per compile time i needed to be a bit creative or hacky... I simpy added a visible boolean value to ListITemData that gets manipulated in the thread. If you want an List item you just get one of the array and set the visible value to true .
To have a look at the full version here are my files
counter-with-jobs-kinda-working.zip

[Vollbrecht]

diff --git a/src/main_old.rs b/src/main.rs
index 564f0fa..1dfbcad 100644
--- a/src/main_old.rs
+++ b/src/main.rs
@@ -9,12 +9,16 @@ use std::rc::Rc;
 
 use std::{thread, time};
 
-use std::borrow::BorrowMut;
+use std::borrow::{BorrowMut, Borrow};
 use std::{sync::Arc, sync::Mutex, thread::Thread};
 
 use std::collections::HashMap;
 use std::vec::Vec;
 
+use once_cell::sync::Lazy;
+
+static GLOBAL_ID2INDEX: Lazy<Mutex<IdMap>> = Lazy::new(||Mutex::new(IdMap::default()));
+
 fn nextId() -> i32 {
     unsafe {
         static mut n: i32 = 0 as i32;
@@ -28,46 +32,53 @@ fn main() {
     let ui = AppWindow::new();
 
     let ui_handle = ui.as_weak();
-    let task_id2index = Arc::new(Mutex::new(IdMap::default()));
-    let mut task_data_model = Rc::new(sixtyfps::VecModel::<ListItemData>::default());
-    //let task_data_model_handle = Arc::downgrade(&task_data_model);
-    ui.set_task_data_model(sixtyfps::ModelHandle::new(task_data_model));
 
     ui.on_request_increase_value(move || {
         let ui = ui_handle.unwrap();
         //
         let id = nextId();
-        let mut data = task_data_model.clone();
         let latency = ui.get_latency();
-        data.push(ListItemData {
+
+        let bla = ListItemData {
             id: id,
             progress: 0 as f32,
-        });
-        let mut id2index = task_id2index.clone();
-        (*id2index.lock().unwrap()).push(id);
+            vis: true,
+        };
+        let data = ui.get_task_data_model();
+        data.set_row_data((id-1) as usize, bla);
+        (*GLOBAL_ID2INDEX.lock().unwrap()).push(id);
+        let ui_thread = ui_handle.clone();
         thread::spawn(move || {
-            let period = time::Duration::from_millis(((10.0 as f32) * latency) as u64);
-            for i in 1..100 {
+            let period = time::Duration::from_millis(((10.0 as f32) * latency) as u64);            
+            for i in 0..101 {
                 thread::sleep(period);
-                sixtyfps::invoke_from_event_loop(move || {
-                    let r = (*id2index.lock().unwrap()).id2row[&id];
+                let r = (*GLOBAL_ID2INDEX.lock().unwrap()).id2row[&id];
+                let ui = ui_thread.clone();
+                sixtyfps::invoke_from_event_loop( move || {
+                    let ui = ui.unwrap();
+                    let data = ui.get_task_data_model();
                     data.set_row_data(
                         r,
                         ListItemData {
                             id: id,
                             progress: i as f32,
+                            vis: true,
                         },
                     );
                 });
             }
             thread::sleep(time::Duration::from_secs(1));
-            sixtyfps::invoke_from_event_loop(|| {
+            let ui = ui_thread.clone();
+            sixtyfps::invoke_from_event_loop(move|| {
+                let ui = ui.unwrap();
                 ui.set_counter(ui.get_counter() + 1);
-                let id2index_g = id2index.lock().unwrap();
-                let mut id2index = &*id2index_g;
+                let mut id2index_g = GLOBAL_ID2INDEX.lock().unwrap();
+                let id2index = &*id2index_g;
                 let r = id2index.id2row[&id];
-                data.remove(r);
-                id2index.erase(r);
+                let mut data  = ui.get_task_data_model().row_data(r);                
+                data.vis = false;
+                ui.get_task_data_model().set_row_data(r, data);      
+                id2index_g.erase(r);
             });
         });
         //pool.add(do_job, id, latency);

[DaMilyutin]

@Vollbrecht, Wow! Thank you for great help and your time!
You made it compile and as you said kind of work.
BTW, great code you wrote!

There is one issue I see. All list items now get into position 0.

I've made some minor enhancements to our (communism; lmao) code.

impl IdMap {
    pub fn push(&mut self, id: i32) -> usize {
        self.row2id.push(id);
        let r = self.row2id.len()-1;
        self.id2row.insert(id, r);
        r
    }
   ... 

        let bla = ListItemData {
            id: id,
            progress: 0 as f32,
            vis: true,
        };
        let r = (*GLOBAL_ID2INDEX.lock().unwrap()).push(id);
        println!("(id, row, latency) = ({}, {}, {})", id, r, latency);
        let data = ui.get_task_data_model();
        data.set_row_data(r, bla);

but this does not solve the issue...
Any ideas?

Try to have dynamic model...

Maybe One has to redefine Model impl like it is made here
https://sixtyfps.io/releases/0.1.5/docs/rust/sixtyfps/trait.model#
But I have no bloody Idea how to make types match!
How do I assign that model into ui.set_task_data_model( <<<here>>> ); ??
AFAICS. there is no push or insert for generic ModelHandle but there is set.
(This looks surprising to me. I guess, it is Rust feature that you can modify data but not size. )

@ogoffart , is there a way to extend ModelHandle. I've seen example with VecModel.
Maybe, I can somehow obtain it from ModelHandle. Is it possible?
If ModelHandle is kinda pointer to base class can I do "dynamic_cast" to VecModel?

[Vollbrecht]

i must have been wrong with the fixed size of the arrays. i checked the memory example again and there is an good example how to increase the size of an array in the .60 file . in the case of the memory example initialy the array is only 8 elemnts big, its gets cloned and doubled in the end. look through this i think it will help.
But this has nothing to do with the shared state question. you cant access this directly in multiple threads

[DaMilyutin]

@ogoffart , @tronical , @Vollbrecht , Hi all.
I've managed to succeed with Rust example similarly to what I've done for C++.
async calls
Use it as you please.

I've accumulated some experience and I'd like to give you feedback on interfaces...
and how many difficulties I've had with Rust part.
But I'll write it a little later.

@ogoffart, Needed to read your answers more attentively though. Thank you for guidance!

P.S. Happy New Year!

[DaMilyutin]

@ogoffart , @tronical , @Vollbrecht
My feedback on my sixtyfps+Rust experience.
First, I like sixtyfps. I've had some experience with Qt so maybe some functionality I've expected to be similar to that. Actually my C++ workers example was based on some other project I've done in Qt. Of course I had some thing to learn but not that much as with Rust.

What can I tall about my experience with Rust?
I'm going just to share my experience and throw some ideas. (Which may be quite naive or obvious, Probably, there is quite better way to write code than I did. But I could not see it "out of the box".)

Main thing which was hard for me was passing data around.
I dislike amount of boilerplate I had to write to obtain data and keep those in sync.
I have VecModel for ListItemData and I also have IdMap for keeping this map in accordance. So actually these two data structures are in sync by design. However, I had to do trickery with as_any(). So I had to seperate list_data and obtain it via passsed around weak ui_handle and with getter. As for IdMap, I had to wrap it in Arrc and Mutex to pass in worker thread and then back to main thread. (Probably Arc could be omitted)
Since I create variables on stack in main thread and then I update those in main thread via invoke_from_event_loop, seems to me it is really needless to wrap them into (Arc and) Mutex. Thus, I think there should be some kind of wrapper to pass references to data around but update them only in main thread.

Ideas that I have...

1. What if I could pass lambdas to worker thread which captured all needed references in main thread? Then I could call invoke_from_event_loop(lambda, arg1, arg2,..., argN) if args are posiible. This will allow to get rid of Arc and Mutex if I get things right. Maybe, not lambda but something callable?
2. Another way is to have Model to be threadsafe and its references to be passed around.
3. Some sort of messages to be sent to main thread. Maybe lambda with parameters.
   Quite vague though.

Extra thing what confused me was that VecModel has semantics of "mutable reference".
So this helped to update it with as_any() trick. but I expected it to have "const reference" semantics so I wrote extra stuff which obviously didn't work until I've figured out the case.
So I think there is some code-smell in VecModel to be mutated by const reference (or I just need to get used to Rust approach).

That's probably it. Quite an essay I wrote. I hope this will be some use for you.

[Futsch1]

What is working as well is to define a callback in your .60 file and request the invocation of that callback from another thread. It's not quite what callbacks are designed for in sixtyfps (I think), but it might simplify the handling of shared states.

gui.clone().upgrade_in_event_loop({
    move |handle| {
        handle.invoke_my_callback(param_a, param_b);
    }
});