Signals and thread safety

[Net5F]

Hello, I'm looking to use the entt signal system for my Sim -> UI communication. My sim and UI currently run on the same thread, but I'm thinking a bit towards future-proofing by making sure my data flow can be made thread-safe.

My first thought on how this should be connected is that the registry (and other sim classes with signals) would be passed to my UI so it can connect to the desired signals. Then, the sim would run at some point and emit signals as appropriate. To make it thread-safe however, the signals would have to be queued. Then, they could be safely dispatched by the UI thread when it comes around.

Is there a way to do this with entt signals? Reading the docs it seems like that might be where collectors come in, but I'm having some trouble seeing how it all comes together.

[skypjack]

Out of the box, signal support for storage classes isn't thread safe. It fits the way one should use an ECS, that is, by elaborating different component types in parallel.
However, signal support is just a mixin. If you do want to make it fully thread safe, you can by switching it off and replacing it with your own implementation.
That being said, I would probably spawn signals as components in my simulation, then have a system at the end of the loop that forwards all these items to their listeners. This way, you don't have to reinvent the wheel or add yet another layer on top of something that works already for what you're looking for.
Dunno if it's clear, let me know in case it is not and I can try to elaborate a little further (not on Sunday though 🙂).

[Net5F]

I think I understand, would it be right to say that signals such as the ones from a registry are more for directly managing the ECS from within the surrounding module (in my case, the "sim")? As such, a different mechanism should be used for communicating with other modules (such as my UI)? That seems reasonable to me.
For my use case, I think that your "push signals as components to be handled by the last system" approach would still require a separate synchronization mechanism (to avoid emitting signals that modify the UI's data as it's being rendered). I could do this using a separate event queue or queued signal library, though.

[skypjack]

It's as right to say as you've the same tastes as me in terms of design. 🙂 🤷‍♂️
I prefer to decouple the two worlds and to setup a mechanism on the border to map things from within the sim to outside. The same goes for signals ofc.

I think that your "push signals as components to be handled by the last system" approach would still require a separate synchronization mechanism (to avoid emitting signals that modify the UI's data as it's being rendered)

A possible solution can be as simple as the following. Imagine you're running the n-th tick of your simulation. You fill a buffer with the signals to send to the UI during the next tick. When it's done, you swap it with the old buffer that was consumed by the UI in the meantime. The sync is on the swap of these pointers, nothing less and nothing more.

[Net5F]

Great stuff, thanks for the help!