I'm currently working on an MVC-esque text editor. A single Model state holds bookkeeping information and, most importantly, a vector of Rows representing the rows in the file. A separate Controller reads input and modifies the Model, and a separate Viewer knows how to display the Model to the terminal. Right now it's all single threaded -- A loop alternates between reading input from the controller and calling for the view to be drawn.
Now that I'm fairly familiar with Rust, I'm eager to try adding concurrency to the project! But this will be my first time with parallelism in Rust specifically, and I'm a little overwhelmed with what patterns will fit best. Currently I just want the View and Controller to run in their own threads while sharing the Model so that user input is handled in parallel, but down the road I want other actors such as a syntax highlighter to also Modify the model in parallel as well. I started going down the path of Mutexes everywhere such as one for each Row in the Model's row vector, but this feels like I'm fighting the language. Should I look into channels and message passing as a solution to any piece of this?
Does anyone have any tips/resources/examples of where to look?
Thank you so much in advance!
It certainly sounds like your design is bad, but the best way to solve it is not necessarily clear. You certainly want some channels, but the best design might involve some sort of mix of channels and mutexes.
Have a look at how Yew implements their UI and state management.
Their docs have a chapter on the various concepts, but the general idea is that your application is a Rust object which implements the Component trait and may store sub-components or state in its fields. The framework then calls a view() method that returns some representation of the UI (think "shadow dom"), setting up callbacks to send component certain messages when things happen. Whenever the component receives a message it will update internal state and tell the framework whether the component needs to be re-rendered. The update() method also receives a Context which can be used to send more messages to the component, meaning you could spin off an expensive task in the background and make it send a message when the task is complete.
I doubt you would be able to use Yew directly, but it should give you ideas for how a UI might be structured.