System Threading #8

New issue

Open

opened 2024-11-23 12:20:35 +01:00 by Booklordofthedings · 0 comments

Booklordofthedings commented

2024-11-23 12:20:35 +01:00

Owner

TODO:

Some way to track if all systems are done
Mutex locking is not required as long as all currently running systems dont overlap in component usage
this means it only needs to track which systems are not done running yet and start the new ones once all systems are done
Systems ordering algorithm
An easy solution here would be to sort systems by the amount of components they consume and pop the largest
then go down the list of each system and check if it doenst overlap, if it doesnt we pop it. This continues until we went through all systems. After that we launch each of the popped systems and wait for them to return. Then we apply their command buffers.
After that rerun the algo and repeat until no more systems are in the list
Command queue
A command queue obejct that by default handles all types of actions that would need to be overlapped. However this should also be exentendable by the user with custom functions to allow them to do waht tehy want.
Essentially a ECSView that only gets applied in a single threaded context

When the user chooses to run systems the ecs should schedule the systems in a way to avoid overlap and then have each system run in a new thread. Actions cannot be done thread indipendently such as creating or deleting entities/components or sending messages will be added to a message queue thats run after all systems of a single priority are done. **TODO:** - [ ] **Some way to track if all systems are done** Mutex locking is not required as long as all currently running systems dont overlap in component usage this means it only needs to track which systems are not done running yet and start the new ones once all systems are done - [ ] **Systems ordering algorithm** An easy solution here would be to sort systems by the amount of components they consume and pop the largest then go down the list of each system and check if it doenst overlap, if it doesnt we pop it. This continues until we went through all systems. After that we launch each of the popped systems and wait for them to return. Then we apply their command buffers. After that rerun the algo and repeat until no more systems are in the list - [ ] **Command queue** A command queue obejct that by default handles all types of actions that would need to be overlapped. However this should also be exentendable by the user with custom functions to allow them to do waht tehy want. Essentially a ECSView that only gets applied in a single threaded context