Refactor usage of concurrency with reactor

Terasology does not use or promote a consistent feature set or technologies for handling concurrency.

In some situations the number of threads are over-provisioned, and in some cases its under-provisioned. Some workloads might benefit from more threads but selectively changing the number of threads by hand will lead to over-provisioning on some systems and under-provisioning on another system.

Poor utilization of threads will end up with situations where the kernel is switching between different tasks. If every thread is a CPU bound task then the processor will spend a lot of time context switching between the different tasks.

We propose dropping ThreadManagerSubsystem and use the functionality provided by Project Reactor.

Currently, TaskMaster is used to push tasks to an off thread where the use case of TaskMaster is probably not needed and the spawned thread is mostly unused.

Current situation

• Chunk-Unloader (allocate 4 threads)

  • int list to queue event for BeforeDeactivateBlocks
  • very light load so threads are mostly idle
  • at any moment a single thread will become active

• Chunk-Updater (allocates 8 threads)

  • generates chunk mesh and queue them back on the main thread

• LOD Chunk Generation

• only triggered for handling different levels of lod

• ThreadManagerSubsystem (allocates 16 threads) only used for a couple situations and the fixed number of threads does not properly utilize the number of cores. and hardly used so all these threads are idle.

  • loadingGame
  • create new world
  • saving screenshot

• TaskMaster

  • Behaviors (1 thread)
  • FlexiablePathFinding (4 threads)
  • Pathfinding (1 thread)

---

• drop usage of the ThreadManagerSubsystem easily can be replaced by usage of Observable
• chunk Mesh generator https://github.com/MovingBlocks/Terasology/pull/4786
• remove usage of TaskMaster
  • #4800
  • #4786
  • https://github.com/Terasology/Behaviors/pull/77
  • https://github.com/Terasology/FlexiblePathfinding/pull/24
  • ~~https://github.com/Terasology/Pathfinding/pull/62~~ — module removed
  • chunk unloader probably does not benefit with parallelism
• check whether Reactor threads need to be explicitly configured as daemons so they don’t prevent the process from closing if they get stuck
• LOD Chunk generation uses a custom set of threads easily replaced with logic in this PR (https://github.com/MovingBlocks/Terasology/pull/4786) . we need to do something slightly different because constantly replacing the static mesh is un-optimal and produces a lot of extra traffic between the GPU and CPU.

[keturn]

Reactor explicitly has built-in integration with micrometer, which makes for a good default answer to which of the metrics implementations in #4637 we should use.

[pollend]

some main problems with RXJava. There is a table of mappings that define a flowable, Observable, Single, Maybe, and Completable and mappings from one to the other. 0…N defined for Floablw and Observable but only flowable has backpressure. Single is one element only but Maybe is 0 or 1. Completable is 0 element or error. there are different methods to map one type to another. the inconsistent API is difficult to follow. The mappings make this pretty confusing where reactor has Flux and Mono. Flux is 0…N and mono is just a single object. I like this a lot better then the former.

While working with Flowable I managed to get into a situation where objects getting pushed to my Flowable were not getting handled by the subscriber where this pattern seems to be more reliable with reactor. I was looking at this benchmark comparing the two and found the reactor implementation is quite a bit faster: https://github.com/MovingBlocks/Terasology/pull/4786

https://github.com/akarnokd/akarnokd-misc/issues/7