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
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.
This is excellent! Thank you so much
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.