Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
None
Description
monty said there are too many for him in the gdb. marko lamented need to scroll gdb when debugging.
Tpool was not written with the goal to easy gdb debugging. Its main goal up to now, was to keep the "concurrency level" number of threads on CPU, where concurrency level was deduced from std::thread::hardware_concurrency
This means, with more CPU and enough tasks in the pool's queue, there will be more threads. More threads are also to expect in any situations where background threads are waiting, e.g when there is a contention, but also one task waiting for another task. This, as already mentioned, because we try to keep number of active CPU at the desired level.
But to optimize another objective, happiness of the people debugging the server, we can introduce the limits. The concurrency level, other than std::thread::hardware_concurrency might actually be needed, to account for non-default process affinity.