ThreadUtils creates too many core pool threads for non-blocking worker thread pool
ThreadUtils.NON_BLOCKING_EXECUTOR
is created with a core pool size of Runtime.getRuntime().availableProcessors()
, which can get ridiculously large on systems with large amounts of CPUs.
Nowadays it is not uncommon to find CPUs with 32 or 64 cores, causing 32 or 64 threads to get created respectively.
We should limit the core pool size to max 8 and allow configuring the non-blocking core pool size via a system property, just like simantics.executor.blockingMaxThreads
.
The same problem actually applies to ThreadUtils.BLOCKING_EXECUTOR
which creates a minimum of 8 threads for its core pool and even more if there are more CPU cores in the system.
At some point in the past, before Git history we had to change the blocking executor to use ScheduledThreadPoolExecutor
with [simantics.executor.blockingMaxThreads, Inf]
core thread pool size. This was done to avoid deadlocks caused by having too little blocking worker threads available. Clearly visible here is that the simantics.executor.blockingMaxThreads
property meaning has changed from "max threads" to "core pool size".
I'm not entirely sure about all the repercussions of changing this, but having huge amounts of idling threads hanging around is not a good idea.