On Sun, 24 Dec 2023 02:51:46 +0100 ichthyo <p...@ichthyostega.de> wrote:
(2) since in Scheme-3, the UI has the initiative: you probably know the
UI better than I: has the UI always a reliable clue to know when to
ask for new data?
On 24.12.23 13:39, Will Godfrey wrote:
No. far from it!
How does the GUI know there is new data in order to update it's copy?
Hi Will,
so it seems like we're in a kind of a dilemma here, regarding the
choice of the pattern / scheme best suited for our needs.
Scheme-3 : UI pulls
Pro
+ can be adopted more incrementally
+ is closer to what happens currently in the code
Con
- is wasteful if we do a round-trip on each GUI redraw
- gets rather complex if we want to avoid that, since then the GUI
must figure out somehow when to call into the core
- serving the calls from GUI can interfere with processing in the core,
as a mitigation, need locking / synchronisation in the core
- problems with possible timeouts due to async response from the core
Scheme-2 : Core pushes
Pro
+ is overall more straight and clean
+ updates happen precisely when they are necessary
Con
- requires to establish some new global infrastructure
- requires locking / sync in the GUI to avoid interference with ongoing draw
- GUI counterpart must detach reliably, or some other scheme to isolate or
protect core against pushing towards a GUI that's no longer there.
Originally everything was directly accessed both ways, with a wasp-nest of
mutex locks. It took a long time to work through that lot, and maybe as a
result I'm now overly hostile to mutex!
...maybe you can reframe that into being cautious against any kind of using
shared data. Because, at the end of the day, /any/ thread synchronisation /
locking / hand-over is always challenging, complicated and laborious.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
