Refactoring Rift reactor system

[alle-ox]

I'm back after a short break, and want to continue refactoring Rift.
After many tries to refactor reactor and manager system, think I have found a good solution.
I have already tried to move managers' system to separate actors with communication via channels/event-bus, but have problem with event ordering and processing.
And another my try it is decoupling each manager's state from reactor "god" struct via Arc<RwLock>>, but tangled in hell lock/unlock hell.

And I decided that the best option is to use ECS hybrid version.
It has many features like change-detection, scheduler, and "world" inspector for debugging purposes.
Also, it is more CPU cache-friendly (high cache locality for data), because ECS has data-oriented design and it has better extendability.
Under ECS Hybrid, I mean: ECS for core state management, channels/event-bus for managing native UI elements, and using bridges for syncing state between macOS and ECS state.
For ECS use bevy_ecs, for channels tokio channels or crossbeam
I understand that rewriting actor system to ECS is rewriting big part of Rift. And want to discuss it with you @acsandmann
Want to discuss pros and cons of this solution, and maybe we can find a "middle ground" or another solution.

[acsandmann]

hmm, i have to think about this. im not too familiar with bevy_ecs so i will have to read up on it. sounds like it would really simplify a lot of the codebase and cure some of the annoyances that exist regarding fragmented state though

[tmandry]

Glide author here, hope you don't mind me chiming in. The reactor being a "big ball of state" is an issue for the organization of code, and I can see patterns like ECS helping with that.

I would caution against replacing the actor architecture wholesale. That is a very natural fit when you think about the core of a window manager on macOS has to do.. issue requests to multiple external processes with their own serial event loops. Keeping the management of a given process's state confined to one single-threaded actor (sometimes extended with timeouts, async tasks, etc) makes it easy to reason about. At this layer of the system limiting shared state is important. The ability to record/replay everything going into the reactor also benefits debugging quite a lot, though I have used it less as Glide matured.

Previously when I tried to use a more object based framing with shared state like in Swindler it became a giant ball of mud and this has been much nicer to reason about overall, which is why I am skeptical of any drastic changes. Another option is to keep the actor model for the system bits but then apply ECS pattern once you get to everything the reactor owns and maybe UI.

P.S. I actually took inspiration from ECS for the tiling model (hence the Components struct); I imagined eventually supporting plugins that can define their own components, attaching data to nodes in the tree.

[acsandmann]

i do agree that the actor system is a good fit. i think our issues are generally more confined to maybe splitting the responsibilities of the reactor up a little so it is less of a big ball..

ps. thanks for creating glide

[Swoorup]

I have similar experience in my charting visualisation app where I was streaming data directly from external sources. It got to a hairy mess and progress grinded to a halt.

External inputs/clients that emit events that better modelled as actors, single actor per external connection/stream, so you could also care of resiliency and converting them into proper domain model event for consumption where ordering might also be important. And then building your ECS core from this internal domain objects.