Open matze opened 4 years ago
Do you have on concrete ideas on how you would want this to work? :)
I've never worked with GLib but my first impression was that we should probably move all the storage handling to a different thread if we want to stay away from Arc<Mutex>
and keep the &mut
to Storage
.
Once it is on a different thread, we could potentially get away with just doing things synchronously and working off a job queue that is coming from a channel that the main thread feeds into.
Do you have on concrete ideas on how you would want this to work?
Nope, I've only had a cursory look how GLib integrates with Rust's async
(i.e. this release note (see Futures) and this example) but have not further looked into it in particular.
I see where you are coming from but after last night's move of current state handling to the Storage
I don't know if a thread/command queue based model would work that well now. But I am open for suggestions.
Oops … wrong ticket.
Should be possible to integrate with the GLib mainloop running the UI.