There are 2 main problems with it:
- multithreading is hard™ and prone to errors that are hard to debug.
- Determinism: multithreaded code is very non-deterministic which creates problems with desyncs. There are ways around it though.
We need to let portions of code (tasks) get executed in arbitrary order without that order affecting the outcome of any task.
One way to let that happen is let the tasks only read data from the world. Useful for a parallel map and reduce. (like summing the items in all chests in a logistics system).
It would also be useful to update an entity that way. So my idea is to let each task write to/update a single entity and have the game engine group all tasks affecting that entity and execute them sequentially on a single thread in a deterministic order based on the mod that submitted the task and the order in which it was submitted (while letting tasks affecting other entities run on another thread). The state of the other entities that the task will read will be the old state; the updates will only be visible to subsequent tasks in the entity's group and not visible until after all tasks are done and the next tick begins.
This would result in the game engine flip-flopping between serial and parallel once every tick. In the parallel phase each entity queries the state around itself and updates its own state accordingly like a combinator reading the circuit network input (or the combinators that output to that network) and updating its own outputs. In the serial phase everything that needs to update multiple entities at once will run.
One of the additional things that those tasks could do is create more tasks for other entities. This would allow communication between entities where they both need to update.